Code Interpreter
Deployment

Choosing a deployment

Which Compose file or chart to use, and what each one is actually for.

The repository ships several Compose files and a Helm chart. They are not alternatives to pick arbitrarily: each targets a specific situation.

Pick a path

The Compose files

FileWhat it is for
docker-compose.yamlThe default. Builds every image from source, microVM mode on.
docker-compose.prebuilt.ymlSame topology, but pulls published images from GHCR instead of building. linux/amd64 only.
docker-compose.nokvm.ymlOverride layered onto the default file to disable the microVM.
docker-compose.scalable.ymlMulti-worker topology, closer to how the Helm chart lays things out.
docker-compose.scalable.nokvm.ymlThe no-KVM override for the scalable stack.
docker-compose.local-dev.ymlDevelopment conveniences: source mounts and faster rebuild loops.
docker-compose.mac.ymlmacOS adjustments.

The .nokvm.yml files are overrides, not standalone stacks. Layer them:

docker compose -f docker-compose.yaml -f docker-compose.nokvm.yml up

Choosing between them

Evaluating, or developing against the API? Use the default docker-compose.yaml, restricted to one language:

CODEAPI_LANGUAGES=python docker compose up --build

No /dev/kvm on the host? Layer the no-KVM override, and read the isolation caveat: this is a real reduction in the security boundary, not a formality.

Running this for other people? Use the Helm chart and work through production hardening first. The defaults in the Compose files are development defaults: shared secrets are inlined, and LOCAL_MODE=true disables authentication entirely.

What comes up

Whichever path you take, the same set of components runs:

The sandbox never talks to the file server, Redis, or the network directly. Its only outbound path is the egress gateway, which checks a signed capability on every request. See Architecture for the full picture.

On this page