What GKE does differently, and what 3B needs as a result. The install itself is the same as on any cluster: follow the Helm installation guide. Building the cluster, load balancer, TLS, and DNS is yours to design and own.
Platform behavior described here was accurate in August 2026. Google changes GKE defaults and capabilities over time, and we update these guides as we learn of changes. The node compatibility check in the installation guide is always the authority for your own cluster. If something here is out of date, please tell Tines Support.
Cluster and node requirements
Warning: Use GKE Standard, not GKE Autopilot. As of August 2026, Autopilot does not permit the user-namespaced (hostUsers: false) pods that 3B’s gVisor sandboxing depends on, and there is no workaround, so choose Standard before you build the cluster. Should Autopilot gain support for user namespaces, verify it with the node compatibility check on a throwaway cluster before planning a deployment around it.
Beyond that choice, Standard clusters usually need no node preparation at all: Container-Optimized OS on a current GKE version gives you the containerd 2.x runtime and the kernel that user namespaces need.
Confirm it on your actual nodes with the node compatibility check in the installation guide before you install.
Load balancing
Route to the chart’s nginx service on port 80 and nothing else. It host-routes all four hostnames internally, so one load balancer covers the whole deployment.
3B’s UI holds a long-lived websocket for real-time sync, and a Google Cloud load balancer applies a 30 second backend timeout by default. That cuts the connection constantly and surfaces as a UI which loads and then silently stops updating. Raise it with a BackendConfig bound to that nginx service; we run one hour.
The binding is a service annotation, so it lives on 3B’s service rather than in your infrastructure:
kubectl -n 3b annotate service nginx --overwrite \
cloud.google.com/backend-config='{"default":"3b-backendconfig"}'
Note: A helm upgrade can reset service annotations, so re-apply this after upgrades. It is the most common cause of sync breaking on GKE after a version bump.
TLS
Google-managed certificates are issued in a strict order, which catches people out because the last step is the slowest. Google will only issue the certificate once the load balancer exists and your DNS already resolves to it. Once DNS is correct, issuance usually takes another 15 to 60 minutes.
So plan the sequence: reserve a static IP first, create the DNS records against that IP, then create the load balancer, and expect to wait. A certificate sitting in Provisioning for a long time nearly always means DNS still isn’t resolving to the load balancer, rather than anything being wrong with the certificate itself.
If you would rather manage certificates yourself, 3B works either way: terminate TLS at the load balancer, or let the chart’s nginx do it. See TLS termination.
Storage
GKE’s default standard-rwo StorageClass satisfies the chart’s persistent volume claims with no configuration. For anything beyond a trial, prefer an SSD-backed class, as the database and sandbox runtimes are latency-sensitive. See sizing for volume sizes.
Troubleshooting
Certificate stuck in
Provisioning— DNS is not yet resolving to the load balancer address. Confirm resolution, then wait.Real-time sync drops every 30 seconds or so — the
BackendConfigannotation is missing, or an upgrade reset it. Re-apply it.apiorworkerpods stuck creating with aprocorrootfsmount error — the cluster is Autopilot, or the nodes are too old to support user namespaces.ImagePullBackOff— the pull secret is missing or its credentials are wrong.
