Heroku Dynos - Configuration

When you deploy or scale your app, Heroku will automatically create one or more dynos, each loaded with the same stack and slug representing your application. Heroku's Dyno Manager then executes the command you provided in your configuration file to start your application running on Heroku. Heroku enables developers to fine-tune their app’s runtime resources by choosing from a broad range of dyno types and dyno configurations to create a “dyno formation.”

Dyno configurations

Most modern applications are composed of interacting pieces. For example, a typical web application may have a web component that is responsible for handling web traffic. It may also have a queue (on Heroku typically represented by an add-on), and one or more workers that are responsible for taking elements off of the queue and processing them. Heroku lets you create this kind of architecture by allowing you to configure your dyno formation with dynos of a specific “process type.”

Process types

Heroku apps use a single configuration file, the "Procfile," to specify the process types needed to run the app. Each process type represents a command that should be executed by the Dyno Manager when starting a dyno. There are three primary process types:

Web dynos: receive HTTP traffic from routers and typically run web servers.
Worker dynos: execute anything else, such as background jobs, queuing systems, and timed jobs.
One-off dynos: are temporary and not part of an ongoing dyno formation. They run short-lived commands, possibly attached to a local terminal, and are typically used to handle administrative tasks such as running a REPL shell to execute database migrations or occasional background work.

Each process type can scale horizontally by increasing the number of dynos running that process, or scale vertically by increasing the size or performance of the respective dynos. When you deploy a new version of your app, the currently executing dynos are replaced with new ones, preserving the existing dyno formation.

Your app may run any number of dynos in almost any configuration. The dynos are only distinguished by the fact that they run a different initial command—they all use the same stack and slug. For example, you can have multiple worker dynos, each with a different start command, in order to break your app down to execute different tasks in different dynos. You can scale each process type independently, as needed.

Leveraging Worker dynos and Heroku’s powerful background processing capabilities allows Conifer to efficiently slice and dice their media files and provide curated content to their clients.
Brendan Hennessy Co-Founder and CTO, LaunchPad Lab LaunchPad Lab’s story →

Dyno types

Heroku offers many different dyno types, each with different features, functionality, and pricing. Developers can choose the dyno types that best fit the resources their app will need for optimal performance.

The following dyno types are available on the same multi-tenant dyno runtime, called the “Common Runtime:”

Eco dynos: are ideal for testing ideas or running apps that see intermittent use. This plan includes a monthly allocation of dyno hours. You can run one web or worker dyno that will sleep after 30 minutes of inactivity (to conserve remaining dyno hours for the month).
Basic dynos: are perfect for small scale projects. These dynos do not sleep. For each app, developers can configure up to 10 process types, each running on one (1) Basic dyno. For running professional projects that require easy horizontal scalability, use Standard dynos or above.
Standard dynos (1x or 2x): provide simple horizontal scalability, enhanced visibility, performance, and availability for powering professional apps.

These dyno types are single tenant:

Performance dynos (M or L): provide superior performance when it’s most critical for extreme-scale, high traffic apps on the Common Runtime.
Private dynos (S, M, or L): available only in Heroku Private Spaces Runtime within Heroku Enterprise. Read more about how dynos work in Private Spaces.

Regardless of dyno type, Heroku ensures isolation and security for all dynos using Linux containerization.

Heroku Add-ons and dynos

Heroku maintains a robust ecosystem of add-on services that support every state of app development and operation. A range of Heroku Add-ons provide dyno support, including Heroku Scheduler that runs scheduled jobs and Process Scheduler that helps conserve dyno hours. Because dynos do not share file state, developers often need to leverage a storage mechanism to enable communication between dynos in an app. Many Heroku apps use add-on such as Heroku Redis, Heroku Postgres, or Apache Kafka on Heroku as the backing mechanism in a queue.