00DB

Kubernetes Install Guide

Works the same way on any Kubernetes cluster — AKS, GKE, EKS, or on-prem — since this is a plain Helm chart with no cloud-specific setup. What it installs, honestly, is smaller than "run one command and you have a working sandbox": read this page before you start.

Step 1 — install the chart

This creates a namespace-scoped ServiceAccount, a Role, and a RoleBinding — the exact RBAC described on Zero Trust. It deliberately does not start a running 00DB server: an earlier draft of this chart included a Deployment, and a Deployment would silently defeat self-destruct by recreating any pod it manages that gets deleted — see Zero Trace. It's been removed for exactly that reason.

helm install 00db ./deploy/helm/00db --namespace 00db-sandboxes --create-namespace

Two values matter, both defaulted sensibly and both needing to match whatever creates a sandbox pod (Step 2 below):

sandbox.namespace — default 00db-sandboxes. Every sandbox pod is created in, and this RBAC is scoped to, this one namespace.
serviceAccount.name — default 00db-sandbox-manager. Whatever creates a sandbox pod must set this exact name as that pod's spec.serviceAccountName, or the pod won't have permission to delete itself later.

Step 2 — something still has to create the sandbox pod

Worth saying plainly rather than glossing over: this chart sets up permissions, it doesn't create sandbox pods itself. Today, that's a separate, human-operated program that isn't distributed as part of this repo or this chart — it needs kubectl apply (or equivalent Kubernetes API) access to create a two-container pod (the 00DB app image plus a database engine image, see Supported Databases) into the namespace from Step 1, with spec.serviceAccountName set to the Step 1 ServiceAccount name. If you're setting up a real environment, talk to your Tribal Knowledge contact about getting that piece running — it isn't a self-serve download today.

Step 3 — license the pod

Contact sales, then generate a license key from your Dashboard. Set it as the SQL_SIMULATOR_LICENSE_KEY environment variable in the sandbox pod's manifest (the same manifest Step 2's launcher applies) — your cluster checks in automatically once a pod starts with that variable set, and unlocks whichever tier the key is for.

What happens once a pod is running

From here, the pod is fully self-managing — nothing further to install or run. It provisions its own sandbox database login against its sibling engine container, connects to the Kubernetes API using the Step 1 ServiceAccount's own in-cluster credentials (not a kubeconfig file), watches its own idle/lifetime clocks, and deletes itself when one of them fires — see Zero Trace for exactly when.