3B is reached through four external URLs, all served on ports 80/443 by the built-in nginx front end and routed by hostname and path. Plan your URLs, DNS, and firewall rules before you install.
The four external URLs
URL | Setting | Purpose |
UI |
| The app users sign in to. |
API |
| The application programming interface. |
Public |
| Addresses 3B shares externally — webhooks and public links. |
Zero sync |
| The real-time sync service that streams data and changes to the UI over a persistent connection. |
Hostnames and DNS
On new installs, the UI, API, and Zero sync URLs share a single hostname (they are routed by path behind that one origin), and the public URL gets its own hostname. So a typical 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. Stacks upgraded from older releases, and the Kubernetes platform guides, may instead give each of the four URLs its own hostname — that split-hostname model remains fully supported:
3b.example.com A <address> (UI) 3b-api.example.com A <address> (API) 3b-ws.example.com A <address> (Zero sync) 3b-public.example.com A <address> (public)
Either way, DNS is required: the services share ports 80/443 and are told apart by hostname, so an IP-and-port-only are 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 standard install | Downloads the small |
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.