Dyno Runtimes

Last updated 28 March 2017

The Dyno Runtime is a central component of Heroku that is responsible for running your app’s dynos. A Dyno Runtime is responsible for:

• Provisioning dynos (secure, isolated containers for running your app’s code).
• Managing and monitoring the lifecycle of each dyno.
• Adding and removing dynos when the scaling configuration of the app changes.
• Providing proper network configuration so dynos can make network requests to attached add-on services and other external endpoints.
• Receiving web traffic on an application’s domain and routing it to web dynos.
• Capturing log output from each dyno and forwarding it to the application’s log drains.

Heroku has two types of Dyno Runtimes: the Common Runtime, and the Private Spaces Runtime. The main difference is the network topology and level of isolation.

See Dynos and the Dyno Manager to understand how the Dyno Manager behaves for each type of Runtime.

Common Runtime

The Common Runtime runs and manages dynos in a single multi-tenant network per region. Two regions are available, US and EU. Each dyno is secured with strong firewall rules so even though all dynos run in a single, flat network, they are strongly isolated from each other.

Dynos in the Common Runtime can only receive connections from the routing layer, which is responsible for correctly and securely forwarding inbound web requests to dynos. Only web dynos can receive connections in this way.

Private Spaces Runtime

The Private Spaces Runtime allows you to create applications in one or more Private Spaces. Each Private Space has its own network, routing layer, and control plane that are not shared with other applications outside the space.

The isolation and network topology of Private Spaces offers several additional benefits, compared to the Common Runtime:

• Access to all applications in a space can be restricted to a set of trusted IP ranges.
• All requests made by apps originate from a set of stable outbound IP addresses allowing you to use IP whitelisting to secure access to various backend services such as an on-premise web service gateway.
• Dynos within a Private Space can communicate directly with each other over a private network.
• Dynos within a Private Space can communicate directly over a private network with certain types of add-on resources such as Heroku Postgres and Heroku Redis. A database or Redis instance created in a Private Space cannot be accessed directly over the public internet.
• The strong isolation allows applications to meet compliance requirements above and beyond what is possible in the Common Runtime.

Choosing a Dyno Runtime for your application

The Dyno Runtime for an application is set at creation time. The Common Runtime is the default.

If you want to use the Private Spaces Runtime instead, see the Private Spaces article.

See the Regions article for information about how to set the region for your app.