How Render handles private networking

When your web service needs to talk to a database, a background worker, or an internal API, that traffic shouldn't go over the public internet. Render's private network keeps communication between your services internal: no VPCs to configure, no subnets to manage, no NAT gateways to set up.

This article covers how private networking works on Render, how to connect your services, and what to watch out for.

How it works

Every Render service in the same workspace and region shares a private network. Services on this network can communicate directly using internal hostnames, without traffic leaving Render's infrastructure.

Private services take this a step further: they have no public URL at all. They're only reachable by other services on the same private network. This makes them ideal for internal APIs, background workers that accept requests, and anything you don't want exposed to the internet.

Each service gets a stable internal hostname (formatted as <service-name>-<hash>:<port>) that you can find in the Connect menu of the Render Dashboard under the Internal tab. Render Postgres databases and Key Value instances also have internal connection URLs for private network access.

Internal traffic between services in the same region is free. It's faster than routing through the public internet and doesn't count toward your outbound bandwidth.

What's on your private network

Not all service types participate in the private network the same way:

All services must be in the same workspace and region to communicate over the private network. A service in Oregon can't reach a service in Frankfurt internally. Cross-region communication requires public URLs.

On Professional workspaces and higher, you can block private network traffic between environments for stricter isolation.

Important: Services on the same private network can reach each other by default. This is a workspace-level trust model, not a zero-trust architecture. If you need service-to-service authorization, implement it at the application layer with JWTs, API keys, or mutual TLS.

Connecting services with a Blueprint

The most practical way to wire up private networking is through a render.yaml Blueprint. Here's a web service that connects to a private worker and a database:

The fromService reference with property: hostport gives you the internal hostname and port (like task-worker-ab1c:10000). The fromDatabase reference with property: connectionString provides the internal Postgres connection string. Render injects both as environment variables at runtime.

Common patterns

Database isolation

By default, Render Postgres databases are accessible from both the private network and the public internet. For tighter security, remove the 0.0.0.0/0 entry from your database's access control list in the Dashboard. This blocks all public connections, so only services on your private network can reach the database.

Web service to background worker

A public-facing web service handles incoming requests and dispatches work to a private service over the internal network. This keeps compute-heavy processing off your request path:

The WORKER_HOST value comes from the fromService reference in the Blueprint, so it always points to the correct internal address.

AI inference pipelines

ML models that serve predictions over HTTP are good candidates for private services. Keeping them off the public internet protects model endpoints from external abuse and avoids exposing inference APIs directly.

Debugging connectivity

When services can't reach each other, the issue is usually one of a few things:

• Wrong URL: You're using the public .onrender.com URL instead of the internal hostname. This still works, but traffic routes through the public internet (slower, and it consumes outbound bandwidth).
• Wrong port: Private services can bind to almost any port, but you need to target the port the destination service is actually listening on. Check the Connect menu in the Dashboard for the correct internal address.
• Cross-region: Services in different regions can't communicate over the private network. Verify both services are deployed to the same region.
• Service type: Background workers and cron jobs can't receive incoming traffic. If you need a service that accepts internal requests, use a private service (type: pserv).

The Render CLI helps with debugging: use render logs to check for connection errors on both the calling and receiving service. The MCP server lets you pull logs and metrics from your editor to diagnose issues without switching context.

Next steps

• Define your private services and database connections in a render.yaml Blueprint using fromService and fromDatabase references
• Lock down your database by removing public access from the access control list
• Add application-layer auth (JWTs or API keys) for service-to-service calls
• Review the private network docs and private services docs for the full reference

FAQ