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:
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 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
Here’s an example from Render’s dashboard:
elastic private service above has the service address
This means you can connect to it directly from any of your services using hostname
elastic-qeqj at port
10000 — 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 Elasticsearch as a search endpoint might require you to specify
http://elastic-qeqj:10000 instead of just
To communicate over the private network, the services need to be in the same account/team and region