3B is reached through two hostnames — the app and public — 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 four URL settings, but only two hostnames:
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. |
| Public (e.g. | Addresses 3B shares externally — webhooks and public links. |
Set the API and Zero sync URLs to the same value as the UI URL. The public URL must use a different hostname.
Hostnames and DNS
An install needs two DNS records, both pointing at your server or load balancer:
3b.example.com A <address> 3b-public.example.com A <address>
The single-server installer proposes exactly these defaults from your root domain, 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. The cookie domain is the shared parent domain of your hostnames (for example example.com), used for sign-in cookies.
If you set a public wildcard domain (PUBLIC_WILDCARD_DOMAIN), also create a wildcard record (*.public.example.com) and make sure your certificate covers it.
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.