Heroku - 4 Features and Architecture v4

This lesson focuses on Heroku's platform features and how they help managing an application. As we already saw, Heroku supports several languages — Java, Node.js, Python, Ruby and others. Pushing your source code is a starting point, but it is not enough on its own: most modern applications rely on pre-built dependencies. To run an app correctly, Heroku must learn which dependencies it needs. So Heroku expects two things: the source code, and a description of the required dependencies.

Buildpacks and the slug

The dependency description varies by language:

  • Ruby: Gemfile
  • Python: requirements.txt
  • Node.js: package.json
  • Java: pom.xml

From the source code and that file, Heroku is smart enough to know how to run your code: it installs the dependencies first, then starts the app. The component responsible for understanding the dependencies and producing a runnable artifact is the buildpack. Its job is to fetch the dependencies the application needs, and to prepare any additional data required to compile and run the code (think non-code assets like videos, images and so on). At the end of this process, the buildpack packages everything into what Heroku calls a slug.

Config vars, add-ons and releases

Once the slug is ready, Heroku injects the config vars: credentials and environment variables, accessible from the running code. You may wonder why these are not in the source code itself. The main reason is security: anyone with access to the source code would otherwise see sensitive credentials. Config vars also help when you have copies of the app for testing — each copy can have its own database credentials without touching the production database. Finally, changing a value without changing the code is safer and faster: edit the variable, restart the app, you are done.

Add-ons are the last piece. They can be databases (PostgreSQL, MongoDB), caches (Redis, Memcached), search engines (Elasticsearch), and much more. The buildpack prepares an instance ready to be consumed, and the service provider configures the service for you. The full catalog lives at elements.heroku.com/addons.

Once the slug is built, config vars are set and add-ons are wired in, Heroku has a release. Every release is stored, which means if you deploy a new release that contains a critical bug, you can simply roll back to a previous release and the app is healthy again. Releases are then handed off to dynos, which Heroku describes as Linux containers in the cloud with capacities you can change on demand. Scaling — one of the main benefits of any PaaS — happens through dynos: add more, or pick larger ones, when you need more compute power; the opposite works too when load decreases.

Three ways to push code

Everything above happens automatically; you only push code changes to Heroku. There are three ways to do that:

  • GitHub integration — connect your app to a GitHub repo; every push triggers a rebuild. Recommended when the project has more than two or three people, because it benefits from PR reviews and change tracking.
  • Heroku Git — Heroku's own Git remote, very similar workflow but without GitHub in the loop.
  • Docker — push container images to Heroku's Container Registry and deploy them.

To recap: it all starts with a code change pushed to Heroku, then Heroku resolves dependencies and prepares any required assets, injects the config vars, attaches the add-ons, produces a release, and finally hands the release to a dyno that runs it. See you in the next lesson.

Summary

Heroku automates the entire application deployment pipeline by taking your source code and dependency manifest, using buildpacks to install dependencies, injecting configuration variables for security, provisioning add-ons (databases, caching, search engines), and packaging everything into releases. The platform executes these releases on dynos—cloud-hosted Linux machines that can be scaled up or down based on your application's computational needs, with the ability to instantly roll back to previous releases if issues arise.

Key points

  • Buildpack System: Heroku's buildpack interprets your project's dependency file (Gemfile, requirements.txt, package.json, pom.xml) and automatically resolves and installs all required dependencies before running your application code.
  • Configuration Variables: Sensitive credentials and environment-specific data are stored as configuration variables rather than hardcoded in the source, protecting security and allowing different settings across staging and production environments.
  • Add-ons Ecosystem: Heroku provisions managed services including PostgreSQL/MongoDB databases, Redis caching, and Elasticsearch search, with pre-configured connectivity automatically exposed to your running application.
  • Release Management: Each deployment creates an immutable release containing your code, dependencies, and configurations; you can instantly rollback to any previous release if a critical error is introduced.
  • Dyno Scaling: Applications run on dynos (virtualized Linux machines) that can be instantly scaled horizontally (more dynos) or vertically (more powerful dyno types) without modifying your code.

FAQ

Why should I use configuration variables instead of hardcoding credentials in my code?

Configuration variables provide security (credentials aren't exposed in version control), flexibility (easily change settings between staging and production), and best practices compliance. They keep sensitive data separate from your codebase.

How does Heroku automatically know how to run my application?

Heroku detects your language and uses the appropriate buildpack, which reads your dependency manifest file (package.json, pom.xml, etc.), installs all dependencies, and then launches your application. You only push code; Heroku handles the rest automatically.

What are dynos and why does Heroku use them?

Dynos are virtualized Linux containers in Heroku's cloud infrastructure where your application runs. They allow easy scaling—you can increase performance by adding more dynos or upgrading to more powerful dyno types, all without any code changes.