Every 3B deployment — from the single-server quick start to a production Kubernetes cluster — runs the same set of components. This page describes what they are, how traffic reaches them, and the properties of the platform they run on.
Components
Component | Kind | Purpose |
| Deployment | The front door. Serves all inbound traffic and routes each request to the right service by hostname and path. Optionally terminates TLS. |
| Deployment | The application server: the UI bundle, the API, sign-in, and workflow editing. |
| Deployment | Schedules and coordinates workflow executions. |
| Deployment | Executes workflow steps. Runs untrusted automation code inside gVisor sandboxes via its |
| Deployment | Serves the addresses 3B shares externally — webhooks and public links. |
| Deployment | The real-time sync service (Zero). The UI holds a persistent websocket to it and receives data and updates as they happen, instead of polling the API. |
| StatefulSet | The database: spaces, workflows, users, and run history. Can be replaced with an external Postgres. |
| StatefulSet | File storage: attachments and the blob store. Can be replaced with S3 Supported Storage. |
| Job | A one-time database migration job that runs on every install and upgrade, before the application services start. |
How traffic flows
3B is reached through four external URLs — UI, API, public, and Zero sync. All of them are served by nginx, which routes by hostname and path:
DNS → load balancer (TLS) → nginx → api / zero-sync / public
Because the chart ships its own nginx reverse proxy, no ingress controller is required — all you need in front of 3B is a load balancer (or, on a single server, DNS pointing straight at the host). See connectivity requirements for the URL, DNS, and port details.
Sandboxing
3B runs untrusted automation code inside gVisor sandboxes with per-job isolation. This is a defining property of the platform and drives its infrastructure requirements:
Nodes must be x86_64 (amd64) Linux. Arm and other architectures are not supported.
The
apiandworkerpods run withhostUsers: false, so the node must support user namespaces: containerd 2.x, a recent kernel, and theuser.max_user_namespacessysctl set to a non-zero value. Some hardened node images ship with this disabled; the deployment guides cover verifying and enabling it.
Storage
Postgres and the blobstore each claim a persistent volume through the cluster’s default StorageClass. Both are sensitive to disk latency, so use SSD-backed storage. The database can instead be external (for example AWS RDS); it must have logical replication enabled (wal_level=logical), which Zero sync requires.
Identity
A built-in identity provider is enabled by default, so a fresh install is immediately usable — open the UI and create the first account. SSO via SAML and OIDC is supported for connecting your own identity provider.