Private networking between your services: step by step

To let one of your Voroa services call another privately, open the service you want to reach, go to Settings → Networking, and copy its Internal address. Use that address and the port the service listens on from your other service - for example WORKER_HOST=<internal address> and WORKER_PORT=5000. The call goes straight between the two services on the same machine, on any TCP port, without going over the public internet. Both services must be in the same workspace, and each one joins the private network on its next deploy.

When to use the private network

Most apps that grow past one service end up with a service that only your other services should talk to: a background worker that takes jobs from your API, an internal API your front end calls, a cache, a search engine, or a file scanner. Sending those calls through a public address has three costs. The call leaves the machine and comes back, so it is slower. The service needs a public address at all, so it is one more thing on the internet that can be scanned. And you are held to HTTP on ports 80 and 443, when the service may speak something else on its own port.

The private network removes all three. Your services reach each other by an internal address, on any port, the way they would on one server.

Step 1 - Deploy both services in the same workspace

Create both services in the same workspace - for example a web service for your API and a background worker for the job runner. Voroa places the services of one workspace on the same machine whenever that machine has room.

If either service was created before private networking was available, redeploy it once. A service joins the private network on its next deploy, so both services in a pair need to have been deployed since then.

Step 2 - Find the internal address

Open the service you want to call - the worker in our example - and go to Settings → Networking. The Internal address row shows the host to use, with a Copy button.

The internal address is the service’s ID, the same ID you see in the service’s dashboard URL. It does not change when you redeploy. Background workers have one too, even though they have no public address.

If the row says Not available for this service yet, the service has not been deployed since private networking was turned on, or it is a static site. Redeploy it and check again.

Step 3 - Point your other service at it

Add the address to the calling service’s environment variables, together with the port the called service listens on. In our example the worker listens on port 5000:

WORKER_HOST=<worker internal address>
WORKER_PORT=5000

Then read those variables in your code, as you would for any other host:

// Node.js
const res = await fetch(`http://${process.env.WORKER_HOST}:${process.env.WORKER_PORT}/jobs`, {
  method: 'POST',
  body: JSON.stringify(job),
});

Any TCP protocol works, not only HTTP - a database driver, Redis, gRPC or a raw socket all connect the same way. Saving environment variables redeploys the service, so it picks up the new values on its own.

The called service must listen on all interfaces (0.0.0.0), not only on 127.0.0.1. A process that binds to 127.0.0.1 can only be reached from inside its own container.

Step 4 - Check that it connects

Open the calling service’s Logs after it redeploys and look for a successful call to the other service. A connection error there tells you which row of the table below applies.

Keep authenticating calls

The private network decides who can reach a service. It does not check who is calling it. Keep the same authentication between your services that you would use over the internet - an API key or a signed token on each request - so that a bug in one service cannot be used to drive another.

Common private network problems

Frequently asked questions

Does private networking cost extra?

No. There is no separate charge for private networking.

Which ports can I use?

Any TCP port your service listens on. Unlike your public address, the internal address is not limited to HTTP on ports 80 and 443.

Can a background worker receive calls?

Yes. A background worker has no public address, but your other services can reach it on its internal address, on the port it listens on.

Are my two services always on the same machine?

Voroa places the services of one workspace on the same machine whenever that machine has room. That is a preference, not a guarantee: if the machine is full, a new service goes to another machine and the two cannot use the internal address between them. Contact support if that happens.

Can I create a service with no public address at all?

Not yet. A web service always also has its public address. Use a background worker if a service should only be reached from your other services.

Related

• Deploy a background worker on Voroa
• How to add environment variables on Voroa
• SSH access to your service
• Pricing