Ports and network paths
This page turns Gateway connectivity into an ownership decision before it becomes a firewall incident. The platform owner defines placement and service addresses, the network owner approves paths, and service owners decide which public endpoints their applications require. Gateway does not open host firewalls or provide NAT traversal.
The default objective is simple: users reach Gateway and public Ingress over HTTPS; managed Nodes initiate authenticated outbound connections to Relay; internal databases and control interfaces remain private. Add exposure only for a documented product path.
Connectivity summary
Section titled “Connectivity summary”| Path | Purpose |
|---|---|
| Client -> Gateway HTTPS | Console, REST, OAuth, MCP, WebSockets, inference proxy |
Managed daemon -> Relay 9443/tcp |
Authenticated outbound control and supported tunnel traffic |
Internet -> nginx 80/tcp |
HTTP and ACME HTTP-01 where used |
Internet -> nginx 443/tcp |
Public HTTPS Routes and Pages |
| Gateway/daemon -> external providers | DNS, OIDC, email, Git, registries, updates, ACME, AI providers |
| Internal Gateway services | PostgreSQL, Redis, internal gRPC, inference-core callbacks |
The Relay—not the Gateway application—is the public owner of 9443/tcp. Gateway does not open host firewalls or provide NAT traversal. Remote Relay workers must advertise data endpoints reachable from assigned managed hosts.
Keep PostgreSQL, Redis, internal gRPC, the inference core, database owner ports, daemon control interfaces, and binding-specific Docker networks private.
Connectivity direction
Section titled “Connectivity direction”Managed daemons initiate outbound authenticated connections to Relay. Operators normally do not expose daemon control ports to Gateway. Remote Relay workers are the exception: their advertised 9443/tcp endpoint must be reachable from the managed hosts assigned to them.
Ingress nodes receive public application traffic on ports 80 and 443 according to Route and ACME requirements. Docker and Database Nodes do not need public workload or owner ports for Secure Links. A published managed database endpoint is an explicit opt-in and should be restricted independently.
Firewall planning
Section titled “Firewall planning”| Source | Destination | Required when |
|---|---|---|
| User/browser | Gateway HTTPS | Console, REST, OAuth, MCP, WebSockets, Inference |
| Managed Node | assigned Relay 9443/tcp |
Always for managed control and supported tunnels |
| Internet/client | Ingress 80/tcp |
HTTP Route or ACME HTTP-01 |
| Internet/client | Ingress 443/tcp |
HTTPS Routes and Pages |
| Gateway/Node | DNS and update endpoints | Name resolution and signed update download |
| Gateway/Build Worker | Git and registry providers | Source discovery, build input, push/pull |
| Gateway | OIDC, SMTP, DNS, webhook, SIEM, AI providers | Enabled integration only |
| Application client | published database TLS port | Only when direct access is deliberately enabled |
Use provider allowlists and egress policy where practical, but include certificate validation, redirects, DNS, and package/registry endpoints required by the selected feature. Do not use a broad “allow all” rule to hide an unresolved dependency.
Address selection
Section titled “Address selection”Gateway records reported local/public addresses and role-specific service addresses. Choose addresses based on the actual peer path: public clients to Ingress, managed hosts to Relay, cross-node Docker operations to reachable service addresses, and database certificates to the published service IPs.
Changing an address can require DNS updates, certificate rotation, Route migration, or Relay rebalance. Verify every peer before removing the old path.
Verification
Section titled “Verification”Test from the real source network, not only from the destination host. Confirm DNS, TCP reachability, TLS identity, HTTP or gRPC protocol behavior, and Gateway’s reported health. A successful TCP connection alone does not prove authentication or application readiness.
Change and rollback procedure
Section titled “Change and rollback procedure”Before changing a public address, Relay endpoint, firewall rule, DNS record, or certificate identity, list every peer that uses the path and define a period when old and new paths coexist. Lower DNS TTL only when DNS is part of the change, and do it early enough to take effect. Keep the old route available until external verification and managed-node reconnects prove the new path.
Roll back by restoring the previous address, DNS value, certificate, or assignment as one coordinated change. Avoid alternating between configurations while caches and long-lived connections are still active. After rollback, verify Relay sessions, node freshness, Routes, Pages, database bindings, webhooks, and source/provider egress used by the installation.
Operator diagnostics
Section titled “Operator diagnostics”Use a layered check from the actual source:
- DNS returns the intended address.
- The network path and firewall allow the documented destination port.
- TLS presents the expected identity and trusted chain.
- The application protocol completes authentication or health checks.
- Gateway receives fresh owner-reported state.
Record which layer fails. Opening more ports does not correct a certificate, authorization, policy, or application-readiness problem.