Private Network
Communicate securely between services without traversing the public internet.
Your Render services in the same region can communicate over their shared private network, without traversing the public internet:
- Each web service and private service has a unique hostname on the private network.
- These services can listen for private network traffic on almost any port (see below) and use any protocol.
- Free web services can send private network requests, but they can't receive them.
- Each Render Postgres and Key Value instance has an internal URL specifically for private network connections.
- Workflows, background workers, and cron jobs can send private network requests, but they can't receive them.
Private network communication is fast, safe, and reliable. It uses stable internal hostnames and IPs that dynamically map to individual instance addresses (which can change between deploys).
Direct IP-based communication is also supported for advanced use cases.
Need a private connection to a non-Render system?
Port restrictions
Each service can have a maximum of 75 open ports.
The following ports cannot be used for private network communication:
180121801319099
Port 10000 is special for web services:
For a web service, private network traffic to port 10000 always routes to the service's primary HTTP server (the server that also receives public internet traffic). This is true even if that HTTP server binds to a different port.
For example, if a web service binds its primary HTTP server to port 4000, private network traffic to ports 10000 and 4000 both route to this server.
What's on my private network?
Static sites are not on a private network.
Other Render services are on the same private network if they're deployed in the same region and they belong to the same workspace.
With a Pro workspace or higher, you can block private network traffic from entering or leaving a particular environment.
How to connect
These service types each have an internal address or URL:
- Web services
- Private services
- Render Postgres databases
- Render Key Value instances
This value is available from each service's Connect menu in the Render Dashboard (see the Internal tab):
Private services also display this value as their Service Address:
The private service above has the internal address elasticsearch-2j3e:9200. Other services on the private network can communicate with it at this address.
You might need to specify a service's expected protocol in its internal address string when you connect.
For example, you might need to specify http://elastic-qeqj:10000 instead of only elastic-qeqj:10000.
Background workers and cron jobs don't have an internal address, so they can't receive inbound private network traffic. However, they can send requests to other service types on their private network.
Integrating with AWS PrivateLink
With a Pro workspace or higher, you can create secure, low-latency connections from your private network to compatible non-Render systems hosted on AWS:
Use a private link to connect to Snowflake, MongoDB Atlas, or resources in your own AWS VPC.
For details, see Private Link Connections.
Direct IP communication (advanced)
Use this method only if hostname-based communication does not serve your use case.
For advanced use cases, you can send private network requests directly to the IP of a specific service instance. This is most commonly useful for scaled services in the following cases:
- You need to message each running instance of your service individually (such as to pull metrics with a monitoring tool like Prometheus).
- You want to implement custom load balancing logic for your service, instead of relying on Render's built-in load balancing.
Each web service and private service has an associated discovery hostname that resolves to all of its active instance IPs. By convention, this hostname has the format [INTERNAL_HOSTNAME]-discovery (e.g., myapp-ne5j-discovery). To find your service's internal hostname, see How to connect.
Each service exposes its discovery hostname to its own environment via the RENDER_DISCOVERY_SERVICE environment variable. If you manage your services via Blueprints, you can also access another service's discovery hostname (see Referencing service properties).
Example: Obtaining instance IPs
The snippet below shows a JavaScript function that fetches all of a service's instance IP addresses via DNS lookup and prints them to the console. For other languages, use a supported DNS lookup library.
Use a lookup API that relies on the underlying system's DNS resolver.
This ensures that your lookup applies necessary DNS configuration (such as rules defined in /etc/resolv.conf).