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.
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.
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.
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.
Dyno hour pool
See Eco dyno for more info.
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.
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.
The command-line interface for interacting with Heroku apps.
The web interface for interacting with Heroku apps. Available at dashboard.heroku.com.
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.
The service that routes logs generated by Heroku apps to applicable log drains. Located in the US region.
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.
A dyno you can spin up to perform a one-off operation on a Heroku app, such as a database migration.
A collection of Heroku apps that share the same codebase, typically to represent an app’s development, staging, and production versions.
Preboot can help reduce app latency during a release, but there are important caveats to enabling it.
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
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.
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.
The approximate location of the data center that a Heroku app’s dynos run in. Heroku provides two regions to non-enterprise customers:
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
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.
The process of reverting a Heroku app to the state of a previous release. Rolling back creates a new release.
The executable bundle created from a Heroku app’s source code by a buildpack.
The image of an operating system (usually a release of Ubuntu) that runs on a dyno.
A design methodology for the architecture of modern web applications. The conventions of the Heroku platform are largely informed by this methodology.