Private Services


Sometimes you don’t want your service to be accessible to everyone on the Internet. For example, you may want to run an internal cache or database that is only accessible to other services in your Render account. In these cases, you can easily create a private service. Private services can speak any protocol (not just HTTP) and can listen on any port.

Getting Started

Here are a few examples to get you started:

Private Service or Background Worker?

If you’re looking to run a service that is not externally accessible and does not listen on any port, such as a worker that processes messages from a queue, you should use a background worker instead of a private service. While private services also run as processes that are inaccessible to the public, they are expected to listen on at least one port. If the process fails to bind to the port in time, the deploy will fail. Background workers, on the other hand, do not have open ports, and are fantastic for delegating long-running or resource-intensive tasks. If your process requires being accessible on open ports, such as Redis, MySQL, or Elasticsearch, a private service is the way to go. If it doesn’t listen on ports, then a background worker is the right choice.

Connecting to a Private Service

Private services are the same as public web services, but they don’t have a publicly accessible HTTPS URL.

Instead, they have a service address, which is a host:port pair.

Here’s an example from Render’s dashboard:

Private service header with service address redis:6379

The redis private service above has the service address redis:6379.

This means you can connect to it directly from any of your services using hostname redis at port 6379 — the hostname resolves to a private IP address that only your own services can access.

You may need to append a URL scheme to the private service address depending on your app requirements. For example, apps that rely on Redis as a cache might require you to specify redis://redis:6379 instead of just redis:6379.