Networks & firewalls

Two tools that sound alike and do opposite jobs. A Network lets your pods talk to each other privately. A Firewall decides which addresses out on the internet are allowed to reach a pod at all.

Each one is created on its own page, and each one is attached to a pod from the pod side. Creating a network or a firewall attaches it to nothing by itself - that is always a separate step, and it is the step people forget.

Networks

A network is a private, region-scoped network with its own CIDR block. Pods on the same network reach each other directly - on private IPs and private hostnames, using internal service ports (no port mapping, no public internet round-trip).

1. Create a network

1. Open Networks in the console, or click Networks in the side panel. You land on the networks table, with columns Name, CIDR, Status, Health, Region and Updated.
2. Click New, at the top right of the table. You land on the Create Network page. (No networks yet? The empty state's Create Network button goes to the same place.)
3. Name (optional) - a label, unique within your account. Leave it blank and one is generated for you.
4. CIDR - the address range for the network, and the only field the form marks required. It has to be a private range, from one of the three blocks below. A /24 is 254 usable addresses, one of which becomes the gateway, and that is plenty for anything you will run here.
5. Region - where the network lives. The form does not star it, but the create fails without it, so pick one. A network only ever holds pods from its own region and cannot be moved later.
6. Description (optional) - free text for future-you.
7. Click Create Network.

Range	Prefix	A good, boring choice
10.x	/8 to /30	10.20.0.0/24
172.16-31.x	/12 to /30	172.20.0.0/24
192.168.x	/16 to /30	192.168.7.0/24

A range outside those three is rejected with "Invalid private network", and a prefix outside the sizes above with "Invalid CIDR prefix length". Type a host address like 10.20.0.5/24 and we store the network address, 10.20.0.0/24.

You come back to the networks table with the network in it. It provisions in the background: Status starts at Provisioning and reaches Active in seconds. Pods can only join a network that is Active.

Click its name to open it. Four counters run across the top - Address space (the CIDR, its gateway address and the region), IP usage (addresses taken out of the usable range), Received and Sent. Below them, Attached pods lists what is on the network, and Uplink uptime charts whether the network's route to the outside world has been up.

2. Put a pod on the network

Pods join from the pod side, and there are two moments to do it.

While creating the pod:

1. Open New pod, or click New on the Pods page.
2. Choose the Region before you look for the network. The Network (optional) picker only lists networks from the region you have selected, because a pod and its network must be in the same one.
3. Pick the network in Network (optional), which reads "Select network" until you do. Its hint spells out the alternative: "Blank reuses your existing network in this region, or creates one if you have none."
4. Fill in the rest of the form and click Create Pod.

No picker on the form?

Network (optional) and Firewall (optional) only appear on the Create Pod page once you own at least one. On a new account they are simply not there. Create the network or firewall first, then come back.

On a pod that already exists:

1. Open Pods and click the pod's name in the table. You land on the pod's Overview tab.
2. Click the Networking tab. The Private Network card has three rows: Network, Private IP and Hostname.
3. Click Change on the Network row. An Edit Network dialog opens listing the networks available in the pod's region.
4. Pick one and click Save.

Moving a pod to another network restarts it

The dialog tells you: "This resizes the pod and will briefly stop and restart it." Changing a pod's firewall carries no such cost - that one is instant.

A pod with domains mapped to it will not move at all. The change is refused with "N domains are still mapped to the pod via the old network", and you have to unmap them first. Plan the network before you point a domain at the pod, not after.

Either way, the pod takes a private IP out of the range and gets a private hostname, both shown on that same Networking tab. For instance and MySQL pods, the Connection Strings tab also hands you a ready-made Private SSH or Private MySQL command built from them.

Talking between pods on the same network

From inside one pod, reach a same-network neighbour by its private hostname on the internal service port:

ssh ubuntu@web-pod              # SSH on internal port 22
mysql -h db-pod -P 3306 -u root -p
curl http://api-pod:3000/health

The hostname is not the name you gave the pod

web-pod above stands in for a generated hostname, something like i-68f3c21a94b7e05d1c2a4f88. Read each pod's real one off its Networking tab, in the Private Network card's Hostname row, or copy the whole Private SSH or Private MySQL command from its Connection Strings tab. The friendly name in the pods table does not resolve.

No external port needed - those are only for connections coming in from the public internet.

Pods only talk privately when they share the same network, so for a multi-pod setup, create one network and put them all on it.

What leaving the network blank actually does

It does not leave the pod off a network. We look for a network you already own in that same region and put the pod on the oldest one. Only if you have none there do we create a new one for you: 192.168.0.0/24, named at random, described as "Auto-created network", listed with the rest of your networks, and counting toward your network limit.

There is no shared, account-wide "default network". Two pods created with the picker blank in the same region usually land on the same reused network and can reach each other; two in different regions never can. If that matters to you in either direction, pick the network yourself instead of guessing.

Why use them

• Run a database in a private pod and expose only the web pod to the internet.
• Build a multi-pod app where workers talk to a queue privately, with no external-port mapping to maintain.
• Give staging and prod their own networks.

Networks are free.

Firewalls

A firewall is an IP allow-list. Each rule is a source IP or CIDR plus a description - that's it. No ports, no protocols, no directions. Only listed addresses can reach the pod; everyone else is blocked.

1. Create a firewall

1. Open Firewalls in the console, or click Firewalls in the side panel. You land on the firewalls table, with columns Name, Rules, Created and Updated.
2. Click New, at the top right of the table. You land on the Create Firewall page.
3. Name (optional) - something like web-only. Unique within your account; blank gets a generated name.
4. Under Add Firewall Rule sit two boxes side by side. In the left one, the one that reads 192.168.1.1 or 192.168.1.0/24, type the address you want to let in. A bare IP and a CIDR both work: 203.0.113.42 and 203.0.113.42/32 mean the same thing.
5. In the right box, Description, say what it is: my home IP.
6. Click Add. The rule drops into the Rules table below, under the IP Address / Network column, and both boxes clear for the next one. Remove on a row takes one back out.
7. Repeat for each address. A firewall holds 1 to 15 rules. Add the same address twice and the duplicate is dropped on save rather than refused.
8. Click Create Firewall.

Click Add before you click Create Firewall

A rule you have typed into the boxes but not clicked Add on is not part of the firewall. Save with the boxes full and the Rules table empty and you get "At least one firewall rule is required", because as far as the form is concerned you added nothing.

2. Add a rule to a firewall that already exists

Worth knowing by heart, because it is the step you need when a firewall has shut you out.

1. Open Firewalls and click the firewall's name in the table. You land on the firewall's page: its name at the top with a rules count beside it, and the rules below under Allow-listed IP / Network and Description.
2. Click New Rule, at the top right. An Add Rule panel opens above the table. (A firewall with no rules shows "No rules configured" instead, with an Add first rule button that opens the same panel.)
3. IP Address / Network - the address to allow, bare IP or CIDR. Required.
4. Description - Office network, or whatever you will recognise in six months.
5. Click Add. The panel closes and the rule appears in the table.
6. Click Apply Changes, at the top right.

Nothing is saved until you click Apply Changes

Adding, editing and removing rules all happen in your browser first. Apply Changes appears only once there is something to save, next to an Unsaved changes badge by the firewall's name. Leave the page while that badge is showing and your rule is gone.

Once applied, the change reaches every pod using that firewall within seconds. No reboot.

To change an existing rule, click the pencil icon on its row: the same panel opens as Edit Rule with the values filled in and its button reading Update. The trash icon on a row deletes a rule. Both are local edits too, so both still need Apply Changes.

3. Attach the firewall to a pod

Firewalls attach from the pod side, same as networks.

While creating the pod: pick it in Firewall (optional) on the New pod page, which reads "Select firewall" until you do.

On a pod that already exists:

1. Open Pods and click the pod's name in the table.
2. Click the Networking tab. The Security & Public Access card has three rows: Firewall, Public Host and Ports.
3. Click Change on the Firewall row, pick one in the Edit Firewall dialog, and click Save.

A pod has one firewall at a time. Only traffic from a listed address is allowed. Changes take effect within seconds, no reboot. A firewall that is attached to a pod cannot be deleted - you get "Firewall is in use by existing pods" until you move those pods onto another one.

What leaving the firewall blank actually does

It does not leave the pod unprotected, and it does not attach a shared account default - there is no such thing. The pod gets a brand new firewall of its own, holding a single rule that allows only loopback. In practice that blocks all public traffic, your own SSH included. It shows up in your Firewalls list and counts toward your firewall limit. The create form says as much in the hint under Firewall (optional): "Blank creates a firewall that blocks all public traffic - add your IPs to it to reach the pod."

That is on purpose: a pod stays closed until you say who gets in. It also means a pod created this way is unreachable from the internet until you add your own address to that firewall, using step 2 above, or swap it for one of yours. The console does not leave you guessing: for as long as no rule on the firewall allows a public address, the pod carries a blue No public access badge next to its status pill, on its own page and in the pods table, and the Firewall row on the Networking tab spells out what is going on. The firewall itself wears the same badge in the Firewalls list.

Locked out of your own pod

The pod says Running, and nothing you try connects.

Look next to the status pill first. A blue No public access badge means no rule on the pod's firewall allows a public address, which is the whole explanation, so skip straight to step 3. No badge means the firewall does allow some addresses, just not the one you are arriving from.

1. Open Pods, click the pod's name, then the Networking tab. The Firewall row names the firewall in force and links to it. Click through.
2. If the counters are showing across the top of the firewall's page, watch Blocked. A number that climbs while you retry is the firewall turning you away, which means your address is not on the list.
3. Find the address you are actually arriving from. curl ifconfig.me, run on the machine you are connecting from, prints it. Home broadband changes it periodically and a VPN replaces it outright, so the address you allow-listed last month may not be the one you are using today.
4. Add it as a rule and click Apply Changes, per step 2 above.

The in-browser web console gets you a shell on the pod no matter what the allow-list says, so the box itself is never out of reach.

A worked example: a public web pod

Say my-app serves a site on 80 and 443, and you also want SSH into it from your desk.

The rule set people reach for first does not exist here. There is no port column, so "SSH from my IP, HTTP from anywhere" is not two rules - it is a contradiction. An address on the list reaches every public port on the pod; an address that is not on it reaches none.

The wrong way

IP Address / Network	Description
203.0.113.42	SSH from my desk
0.0.0.0/0	web traffic

The second rule lets the whole internet in, SSH included. The first rule now changes nothing.

Pick one job per pod instead:

A public web pod gets one rule - 0.0.0.0/0, described as public web traffic - and you secure SSH inside the pod with an SSH key and PasswordAuthentication no rather than with the allow-list. The rules table shows that address as 0.0.0.0 once saved; same thing.

A private database pod gets no public exposure at all. Put it and the web pod on one network and let the web pod reach it on the private hostname. Its firewall can stay the closed one it was born with, because nothing legitimate arrives from the public internet anyway.

A dev box or an internal tool gets one rule per place you work from - your home IP, your office range, your VPN's egress range - and nothing else.

Firewalls are free.

One rule you did not write: outbound port 25

Every network carries a standing rule you cannot see in the console and cannot remove from a firewall: outbound TCP port 25 is rejected.

Firewalls control who reaches in to your pods. This one controls what your pods reach out to, and it exists because outbound addresses are shared. One compromised pod sending directly to mail servers gets the whole address blocklisted.

Sending mail through an authenticated relay on port 587 or 465 is unaffected, as is any provider's HTTP API. If your application hangs or errors while sending mail, check which port it is using before you suspect your firewall; a firewall rule cannot cause it, and a firewall rule cannot fix it.

For a reviewed need, ask us to lift it for the account.

API

• Networks API
• Firewalls API