Networking
Last updated December 03, 2024
Table of Contents
Each dyno has its own network interface. The surrounding network configuration depends on the type of runtime.
Common Runtime Networking
The Common Runtime provides strong isolation by firewalling all dynos off from one another. The only traffic that can reach a dyno is web requests forwarded from the router to web processes listening on the port number specified in the $PORT environment variable. Only web dynos can receive inbound requests.
Individual processes within a dyno can bind to any address or port they want and communicate among them using standard TCP. The external networking interface, for example, eth0, for each dyno is part of a /30 private subnet in the range 172.16.0.0/12, such as 172.16.83.252/30 or 172.30.239.96/30. Processes within one dyno don’t share IPs or subnets with other dynos, nor can they observe TCP session state of other dynos.
All dyno types in the Common Runtime can make outbound requests to services running elsewhere on the internet. You can’t control the originating IP address for these requests cannot be controlled.
Private Spaces Runtime Networking
The are two generations of the Private Spaces Runtime: Cedar and Fir
Cedar Private Spaces
Dynos in Cedar-generation Private or Shield Space are all connected via a virtual private network configured as part of the space. Add-on data services installed in the space are also connected to this network.
Similar to the Common Runtime, web processes can receive web requests by listening on the port number specified in the $PORT environment variable. In addition, any process in a dyno can choose to listen on a port number of choice and receive connections from other dynos on the private network.
Use trusted IP ranges to control which client IPs can communicate with the applications in a space.
In addition, apps in Private Spaces can enable Internal Routing on app creation. Unlike other apps, these internal apps can’t receive external web traffic to their web process type. Instead, their web process type can receive traffic from:
- your other apps running in same space
- software running in VPC-peered or VPN-connected networks
Dynos in a space make outbound connections to other internet services via a NAT gateway, which ensures that all connections originate from a set of stable outbound IP addresses.
Fir Private Spaces
Custom Trusted IPs, Internal Routing, VPC-peering, and VPN connections are unavailable for Fir-generation Private Spaces. Subscribe to our changelog to stay informed on when we add these features to Fir.
As in Cedar Private Spaces, dynos in a Fir spaces are all connected via a virtual private network configured as part of the space. Add-on data services installed in the space are also connected to this network.
Like Common Runtime and Private Spaces, web processes can receive web requests by listening on the port number specified in the $PORT environment variable.
Dynos can connect to services running in VPC-peered or VPN-connected networks. These services can’t reach dynos in a Fir space directly. They must connect to those dynos over the internet via the apps public DNS name.
Dynos in a space make outbound connections to other internet services via a NAT gateway, which ensures that all connections originate from a set of stable outbound IP addresses.
Connecting to External Services
Applications running on dynos can connect to external services. Heroku can run apps in multiple regions, so for optimal latency run your services in the same region as the app.