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.
Here are a few examples to get you started:
- Deploy a private Redis cache
- Deploy Webdis as a web frontend for Redis
- Deploy Sinatra and Sidekiq backed by Redis
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.
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
Here’s an example from Render’s dashboard:
redis private service above has the service address
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