Networking
Last updated October 16, 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
Dynos in a 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.
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.