Firewall & ports
Reconciled UFW rules on a node (desired state, with drift detection and a one-click reconcile) and per-instance port exposures (a node-host port forwarded into the instance) — both desired-state, never fire-and-forget.
Two day-2 surfaces control what's reachable: node firewall rules (firewall rules you set on a node) and instance port exposures (a port on the node forwarded into one instance). For both, the rules you set are the source of truth and the system keeps the live firewall matching them — they're not one-off commands that can drift.
Node firewall rules (UFW)
Where: Node workspace → Security tab → Firewall rules card.
These are firewall rules you set on the node — a custom admin port, or an allow/deny limited to a source CIDR. They're separate from the rules a domain or route creates automatically; this card is for the rules you define yourself.
Adding a rule
＋ Add rule opens a dialog with:
| Field | Values | Notes |
|---|---|---|
| Port | 1–65535 | the node-host port |
| Protocol | TCP / UDP | |
| Action | Allow / Deny | Allow opens it; Deny rejects it |
| From (optional) | a source CIDR, e.g. 203.0.113.0/24 | empty ⇒ any source |
A bad port, protocol, action, or CIDR is rejected before anything is written. On Add rule the
rule becomes active and is applied on the node. Removing a rule (Remove, confirm) deletes it
from the node, then drops the row.
Drift detection & reconcile
Hand-edits to the node firewall are caught
Your rules are the source of truth. If someone deletes a rule on the node outside the panel, the firewall no longer matches — that's drift. Check drift compares your rules to what's actually live; a missing rule shows a Drift detected badge and the row reads drifted. Reconcile re-applies your rules and clears the badge. The drift check is read-only — it never changes the node; only reconcile does.
The flow works cleanly both ways: add → active on the node → someone deletes it on the node → Check drift shows drift → Reconcile restores it → Remove takes it away. Reconciling is safe to repeat.
Instance port exposures
Where: Instance workspace → Network tab → Port exposures card.
A port exposure forwards a TCP/UDP port on the node into the instance — for example, exposing a Valkey/Redis or a database port on the node's IP. It opens the port on the node and forwards it to the instance, with a matching firewall rule.
Exposing a port
＋ Expose a port opens a dialog with a Node-host port (the port opened on the node), an Instance port (the port inside the container), and a Protocol (TCP/UDP). Expose port sets up the forward and the firewall rule.
Remove (confirm) closes both the forward and the firewall rule — the exposure is gone in one action.
Port exposures vs domain routes
The Network → Port exposures card lists only raw port forwards. An HTTP domain route — a hostname with TLS, reverse-proxying to the site — is managed on the site workspace's Domains / Routes tab, not here.
Permissions
Managing node firewall rules needs the firewall-manage permission (admin); operators can view. Port exposures use the same permissions as routes.
Developer access keys
Hand a developer site-scoped SFTP access in two minutes — a per-site SFTP system user inside the instance, confined to the site root, reached via ProxyJump through the node, with a one-line revoke. Never a panel login.
DB console & restarts
Open the site's database in Adminer behind a single-use, short-lived token gate, copy password-free connection snippets, and restart a service (nginx / PHP-FPM / the app unit) from the site workspace — with the panel asserting the unit came back.