3B is reached through two hostnames — the app and edge — served on ports 80/443 by the built-in nginx front end, which routes by hostname and path. Plan your URLs, DNS, and firewall rules before you install.
The external URLs
You configure two hostnames. The installer copies the app URL into the API and Zero sync settings, which are served by path on that hostname:
Setting | Hostname | Purpose |
| App (e.g. | The app users sign in to. |
| Same as the UI | The application programming interface. |
| Same as the UI | The real-time sync service that streams data and changes to the UI over a persistent connection. |
| Edge (e.g. | Addresses 3B shares externally — webhooks and edge links. |
The edge URL must use a different hostname from the app.
Hostnames and DNS
An install needs two DNS records, both pointing at your server or load balancer:
3b.example.com A <address> 3b-edge.example.com A <address>
The single-server installer asks for exactly these two URLs, and the Helm guide’s example values use the same layout.
DNS is required: the services share ports 80/443 and are told apart by hostname, so an IP-and-port-only setup is not supported. Sign-in cookies are scoped to the app hostname; the single-server installer sets the cookie domain to it for you.
If you enable space hosts with EDGE_WILDCARD_DOMAIN, create a wildcard record for the parent of the edge hostname. For EXTERNAL_EDGE_URL=https://apps.corp.example, point *.corp.example at the edge ingress and cover it with a TLS certificate. Space URLs and inbound email addresses use <space>--apps.corp.example. To keep existing dotted URLs, retain their wildcard DNS and certificate coverage, and register the old wildcard as a tenant custom domain.
Inbound ports
Setup | Inbound ports to open |
HTTPS | 80, 443 |
HTTP (evaluation only) | 80 |
On the single-server install, nginx binds host ports 80 and 443 directly. Kubernetes also exposes the same front end on NodePorts 30080 (HTTP) and 30443 (HTTPS) if you prefer to point a load balancer at those instead.
TLS is effectively required
3B expects to be reached over HTTPS, with TLS terminated somewhere in the request path — at 3B itself or at a load balancer or proxy in front of it. This is more than a recommendation: AI providers require requests to arrive over a secure (HTTPS) connection, so configuring them does not work over plain HTTP. See TLS termination for the supported options.
Outbound connectivity
Destination | When | Purpose |
| Install and every update | The Helm chart, container images, and install bundles. The only source of the software. |
| Single-server install and air-gapped bundle build | Serves the |
| Single-server install or bundle build when ORAS is absent | Downloads the small |
| At startup and every 12 hours, from release v3.1.0 | Deployment telemetry — a small report about your deployment. |
Your AI providers, SMTP server, and the third-party services your workflows call | Runtime | Only what you configure and use. |
An air-gapped server needs no outbound access at all.
Behind an outbound proxy? 3B can use it — set HTTP_PROXY, HTTPS_PROXY, and NO_PROXY (or the httpProxy Helm values). Make sure the proxy permits the hosts above.
Workflow egress and internal networks
Workflow code runs in sandboxes whose outbound requests are blocked from reaching private and internal address ranges by default (an SSRF guard). If your workflows must reach internal services, allow the tightest possible CIDR ranges via ALLOWED_CIDR_BLOCKS (single server) or allowedCidrBlocks (Helm) — see the configuration reference for the security implications before widening this.