Networks

A network is a private, region-scoped network for your pods. Pods on the same network talk to each other on private IPs and private hostnames, on their internal service ports directly - no public internet, no port mapping, no firewall hops.

Properties

• CIDR - the private address range, e.g. 10.20.0.0/24. Must be a private IPv4 range, with a prefix from the block's own size down to /30: 10.x allows /8-/30, 172.16-31.x allows /12-/30, 192.168.x allows /16-/30. Fixed once the network is created.
• Gateway - the first usable address in the range, assigned for you.
• Region - a network lives in one region and can only hold pods from that same region. Fixed once created.
• Name - a friendly label, unique within your account. Rename it freely; the name is not what pods resolve.

Same-network communication

When two pods share a network, one reaches the other via:

• The private IP assigned from the CIDR range.
• The private hostname, which is generated and is not the name you gave the pod: i-6a4d5b83b7006ccae6391810 for an instance, d-70a1e4c6b92f3d8a5e1b7c42 for a database. Each pod shows its own on the Networking tab, in the Private Network card's Hostname row.

Both work on the internal service ports - SSH on 22, MySQL on 3306, your Node app on 3000, and so on. No need for the externally-mapped ports when you are already inside the network.

# From inside another pod on the same network
ssh ubuntu@i-6a4d5b83b7006ccae6391810
mysql -h d-70a1e4c6b92f3d8a5e1b7c42 -P 3306 -u root -p
curl http://i-70f1c2a84b9e3d5c1a2b6f40:3000/health

Attaching pods

Pods join a network from the pod side - pick the network when you create the pod, or from the pod's Networking tab later. The network and the pod must be in the same region.

A pod created without picking a network joins your oldest existing network in that Region; only if you have none there do we create one for you, on 192.168.0.0/24, with a random name. It shows up in your Networks list and counts toward your network limit. Pods talk privately when they share a network - so pods created without picking one CAN reach each other, as long as they landed on the same reused network.

Moving an existing pod to a different network is a resize: the pod stops and starts again. Unmap the pod's domains first, or the change is refused - the mapping's routing is tied to the network it was built on.

Use cases

• Run a database privately and expose only the web pod to the internet.
• Multi-pod apps where workers talk to a queue over private addresses.
• Stage and prod isolation, one network per environment.

Outbound mail from a pod

Pods cannot open outbound connections on TCP port 25. The attempt is rejected, not dropped, so your code fails fast rather than hanging.

This is not about your pod. Outbound addresses are shared, and one compromised pod talking straight to the world's mail servers gets that address blocklisted for everyone on it. Blocking the port is what keeps a shared address usable.

Everything else about sending mail still works:

You want to	Works
Send through an authenticated relay on port 587 or 465, ours or anyone else's	Yes
Send through a provider's HTTP API	Yes
Receive mail on a mailbox we host for your domain	Yes
Connect straight to a recipient's mail server on port 25	No

If you have a reviewed need for port 25, talk to us. It is an account-level exemption, so it applies to every network on the account once granted.

Notes

• Networks are free.
• Networks are isolated per account.
• A network is created asynchronously and is ready to use once it goes Active (usually seconds). A pod cannot attach to one that is still provisioning.

See also

• Networks & firewalls guide
• Networks API