Private networking between services

4 min readUpdated April 2026

Apps and add-ons in the same StackBlaze project talk to each other over a private network: never the public internet. Each one is reachable by its internal service name (for example backend) that resolves within your project automatically.

Calling your backend via its public URL adds unnecessary latency, potential egress costs, and routes traffic through the load balancer and TLS handshake for no reason. Internal hostnames skip all of that.

Project network topology

HTTPS publichttp://backend:3000DATABASE_URL
Public Internet

User traffic

HTTPS only

Frontend Service

frontend

public + internal

Backend API

backend

internal only

PostgreSQL

attached add-on

internal only

Service-to-service call

frontend/src/api.ts

// ✗ Never do this, routes through public internet

const res = await fetch("https://backend.myapp.com/api/users")

// ✓ Use the internal hostname, stays in the cluster

const API_URL = process.env.API_URL // "http://backend:3000"

const res = await fetch(`${API_URL}/api/users`)

Auto-injected env vars when you link services

frontend service, environment

# Auto-set when you link the backend service to frontend

API_URL=http://backend:3000

# Auto-set when you attach a PostgreSQL add-on

DATABASE_URL=postgresql://sb_user:***@myapp-postgres:5432/mydb

Under the hood

  • Isolated per project: each project runs in its own private network with a hard isolation boundary. Apps and add-ons inside it resolve each other by short name; nothing outside the project can reach in.
  • Stable internal endpoint: every app and add-on gets a stable in-cluster address under its own name. Calling backend resolves to it automatically, no IPs to hard-code and no configuration.
  • Traffic never leaves the cluster: internal calls go directly from pod to pod on the cluster network. No NAT, no internet gateway, no egress charges. Latency is typically sub-millisecond.
  • Optional mutual TLS: enable the service mesh add-on and pod-to-pod traffic is transparently wrapped in mTLS. Even plain-HTTP internal calls become authenticated and encrypted, below the application layer, with no code changes.

Step by step

01

Everything in a project shares a private network

Apps and add-ons you create in the same project sit on the same private network. Each one is reachable from the others by its internal service name, with no public URL and no manual configuration.

02

Call services by their internal name

From inside your project, reach another app by its service name instead of its public URL, for example http://backend:3000. The request stays on the cluster network, skips the load balancer and TLS handshake, and never incurs egress charges. Use it in environment variables, config files, and SDK clients.

03

No firewall rules needed

By default, everything within the same project can reach each other freely, no ports to open, no security groups, no IP allowlists. If you need to restrict traffic between services, you can apply network policies from the dashboard.

04

Add mutual TLS with the service mesh add-on

For zero-trust encryption between services, enable the service mesh add-on. It transparently wraps pod-to-pod traffic in mutual TLS, so even plain-HTTP internal calls are authenticated and encrypted, with no code changes.