Glossary of Heroku Terminology
Last updated November 28, 2022
Table of Contents
This article provides definitions for terms that are either specific to the Heroku platform or have a specific meaning on the Heroku platform. This is not an exhaustive list of Heroku products and features.
Add-on
A component you can attach to a Heroku app that provides a supporting service, such as data storage, monitoring, or log management. Add-ons maintained by Heroku and third-party providers are available in the Elements Marketplace.
App
A web application on Heroku. Has a set of dynos that run the application’s source code. Has a unique .herokuapp.com URL and release history.
Buildpack
A collection of scripts that transforms a Heroku app’s code into the executable bundle (called a slug) that is run by the app’s dynos.
Heroku provides official buildpacks for a variety of programming languages. Third-party buildpacks for other languages and frameworks are avilable in the Elements Marketplace.
Config var
An environment variable that is available across all of a Heroku app’s dynos. Its value persists across releases and dyno restarts.
Dyno
A container that runs a Heroku app’s code. When a dyno starts up, it runs a single command that is usually specified in the app’s Procfile. For example, dynos for basic Node.js web apps often run the command node app.js to start up a web server.
Dyno formation
The current set of dynos running across all of a Heroku app’s process types. The number of dynos running for each process type can be scaled up and down independently.
Learn more about scaling an app’s dyno formation
Dyno hour pool
See Eco dyno for more info.
Dyno sleeping
When a dyno sleeps, it gets scaled down to zero. This behavior exists only on Eco dynos, to help conserve your pool of dyno hours.
See Eco dyno for more info about how dyno sleeping works with this dyno type.
Eco dyno
The Eco dyno type enables you to host small-scale Heroku apps for a small monthly flat fee. For $5 a month, you get a monthly pool of 1000 dyno hours shared across all of your apps using Eco dynos. Eco dynos come with the following features and limitations:
- If an app has an Eco web dyno, and that dyno receives no web traffic in a 30-minute period, it sleeps (scales to zero). In addition to the web dyno sleeping, if you have a worker Eco dyno, it also sleeps.
- Apps that only use an Eco worker dyno don’t sleep, because they don’t respond to web requests.
- After consuming your pool of Eco dyno hours, all Eco dynos in your account sleep for the remainder of the month.
Heroku CLI
The command-line interface for interacting with Heroku apps.
Learn more about the Heroku CLI
Heroku Dashboard
The web interface for interacting with Heroku apps. Available at dashboard.heroku.com.
Learn more about the Heroku Dashboard
Log drain
A destination (i.e., a URL) that the Logplex service routes all of a Heroku app’s logs to. An app can specify multiple log drains to route its logs to multiple destinations.
Logplex
The service that routes logs generated by Heroku apps to applicable log drains. Located in the US region.
Maintenance mode
A mode you can enable for a Heroku app to prevent all external web traffic from reaching it. This can be useful for performing maintenance tasks such as database migrations.
Learn more about maintenance mode
One-off dyno
A dyno you can spin up to perform a one-off operation on a Heroku app, such as a database migration.
Learn more about one-off dynos
Pipeline
A collection of Heroku apps that share the same codebase, typically to represent an app’s development, staging, and production versions.
Preboot
If a Heroku app enables preboot, on every release, Heroku ensures that the new release’s web dynos are started and receiving traffic before the previous release’s dynos are terminated.
Preboot can help reduce app latency during a release, but there are important caveats to enabling it.
Process type
A Heroku app declares one or more process types to indicate which command its dynos should run on startup. Each dyno belongs to exactly one process type (such as web) and runs the command associated with that process type (such as node app.js).
The web process type is special, because it is the only process type that enables dynos to receive traffic from the internet.
Process types are declared in an app’s Procfile.
Learn more about process types
Procfile
A plaintext file that declares the commands that an app’s dynos run when they start up. The Procfile is always named Procfile without a file extension and lives in an application’s root directory.
A basic Procfile looks like this:
web: node app.js
This example Procfile defines a single process type, named web. Dynos that belong to the web process type run the command node app.js when they start up.
See also: Web dyno, Worker dyno
Region
The approximate location of the data center that a Heroku app’s dynos run in. Heroku provides two regions to non-enterprise customers: us and eu.
Release
A distinct deployed version of a Heroku app. All of the following events create a new release for an app:
- A successful app build
- A change to the value of a config var (unless the config var is managed by an add-on)
- A pipeline promotion
- A rollback
- A release via the Platform API
- Provisioning a new add-on
Release phase
An optional phase that occurs just before a new app release is deployed. Useful if you have commands that should always run before new code goes live, such as database migrations.
Learn more about release phase
Rollback
The process of reverting a Heroku app to the state of a previous release. Rolling back creates a new release.
Slug
The executable bundle created from a Heroku app’s source code by a buildpack.
Stack
The image of an operating system (usually a release of Ubuntu) that runs on a dyno.
Twelve-factor app
A design methodology for the architecture of modern web applications. The conventions of the Heroku platform are largely informed by this methodology.
Learn more about the twelve-factor app
Web dyno
A dyno that can receive HTTP traffic. These dynos run the command associated with the web process type in an app’s Procfile.
Worker dyno
A dyno that cannot receive HTTP traffic. These dynos run the command associated with any process type in an app’s Procfile except the web process type.