Last updated December 03, 2024

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.

Learn more about add-ons

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.

Learn more about apps

Base image

A base image is an operating system image that is curated and maintained by Heroku. Base images are typically based on an existing open-source Linux distribution, such as Ubuntu. Heroku applications target a specific base image, and buildpacks are responsible for transforming an app’s source code into an executable package that is compatible with that base image.

Learn more about base images

Build Artifact

The term ‘build artifact’ is used to describe both types of generation-specific artifacts.

• The build artifact for Cedar-generation apps is a slug. A slug is a bundle of your source, fetched dependencies, the language runtime, and compiled/generated output of the build system, ready for execution.
• The build artifact for Fir-generation apps is an Open Container Initiative (OCI) image produced by a Cloud Native Buildpack.

Buildpack

A collection of scripts that transforms a Heroku app’s code into the executable bundle run by the app’s dynos. Cedar-generation apps use our classic buildpack API, while Fir-generation apps use the open Cloud Native Buildpack (CNB) specification.

Classic buildpack

Heroku created the concept of buildpacks using a proprietary buildpack API to transform a Heroku app’s code into an executable bundle (called a slug on Cedar). To distinguish between Cloud Native Buildpacks used by Fir, these may be referred to as “classic” buildpacks.

Heroku provides official buildpacks for various programming languages. Third-party buildpacks for other languages and frameworks are available in the Elements Marketplace.

Learn more about classic buildpacks

Cloud Native Buildpack (CNB)

Applications built on Fir use the latest generation of buildpacks known as Cloud Native Buildpacks (CNB). The CNB specification is open and the Cloud Native Buildpack project is a part of the Cloud Native Computing Foundation (CNCF). While a “classic” buildpack produces a slug, a CNB produces an Open Container Initiative (OCI) compliant image that can be used by systems such as Docker and Kubernetes.

Learn more about Heroku’s Cloud Native Buildpacks (CNBs)

Config var

An environment variable that is available across all of a Heroku app’s dynos. Its value persists across releases and dyno restarts.

Learn more about config vars

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.

Learn more about dynos

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.

Learn more about Eco dynos

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.

Learn more about log drains

Logplex

The service that routes logs generated by Heroku apps to applicable log drains. Located in the US region.

Learn more about Logplex

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.

Learn more about pipelines

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.

Learn more about preboot

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 and the Procfile

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

Learn more about the Procfile

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.

Learn more about regions

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

Learn more about releases

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.

Learn more about rollback

Slug

The executable bundle created from a Heroku app’s source code by a classic buildpack.

Learn more about slugs

Stack

For Cedar-generation apps (which use classic buildpacks), the name of an app’s stack is also the same name as its Heroku base image. For Fir-generation apps the name of an app’s stack is always set to cnb , and the base image is selected via project.toml.

Learn more about stacks

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.