Kubernetes is the supported production deployment path for Loom. There are two Helm charts in the
source repository — helm/loom for the server and helm/cortex for the workers.
Install
# Loom with a bundled PostgreSQL (evaluation):
helm install loom ./helm/loom --set postgresql.enabled=true --set auth.initialPassword=<password>
# A Cortex worker pointed at it:
helm install cortex ./helm/cortex --set loom.host=loom --set loom.token=<token>The full guide — values reference, external vs bundled database, custom Cortex worker images and the verification steps — is on the Helm Charts page. For the underlying manifests, the service account, the sandbox guardrails and the worker pools explained step by step, see the Kubernetes playbook.
What the Chart Handles For You
Two things are easy to get wrong when packaging Loom. The chart handles both, but they are worth knowing before you change the defaults:
-
The keystore volume holds the JWT signing key. The chart persists it by default; keep it that way, or every issued token stops verifying after a restart. The configuration volume (
loom.yml) is persisted for the same reason. -
Enabling the coding sandbox (
sandbox.enabled=true) renders the runner-namespace Role, RoleBinding, ResourceQuota, LimitRange and NetworkPolicy together with the feature flag. Setting the flag without that set would produce a deployment that cannot create runners, or creates unconstrained ones — the chart keeps them together.
See Artifacts for the published Maven and container coordinates.