ADR-0004: Container runtime for the original hosted deployment
- Status
- superseded for self-hosting
- Decided
- September 2026 (hosted deployment)
- Applies to this repository
- No. This repository ships Docker Compose (
deploy/compose) and Helm (deploy/helm); see the Deployment Guide.
Context
Before the code was open-sourced, the maintainers ran one hosted instance of the platform on a managed container service (Azure Container Apps) with managed PostgreSQL and Redis, plus one VM for the workloads that service could not host. That runtime choice, and the infrastructure code for it, are not part of what this repository supports.
Decision (historical)
The hosted deployment ran the stateless request-path services on the managed container platform and kept on a VM the services that need what such platforms usually do not offer. Those constraints are properties of the services, so they still matter to anyone choosing a runtime:
| Service | Needs |
|---|---|
redpanda | A block-device volume that supports O_DIRECT (XFS/ext4); network file shares such as SMB do not work. |
livekit | Raw UDP 50000-50100 and TCP 7881 reachable from callers. |
tool-sandbox, code-intel-docker | Linux capabilities or privileged containers (see ADR-0009). |
mcp-stdio-runner | Plain internal TCP between core and the runner, with keepalive (idle flows through cloud NAT or load balancers may be dropped silently). |
What applies to self-hosters
- Docker Compose on one host satisfies all of the needs above; enable the matching profiles (
events,voice,sandbox,tools,code-intel). - On Kubernetes, check the same needs against your cluster: a storage class for Kafka (or an external Kafka), UDP exposure for LiveKit, a
runtimeClassNameor privileges for the sandboxes. - Managed PostgreSQL, Redis-compatible and S3-compatible services are supported through the Helm
global.*values and the Compose database andSTORAGE_*variables.
Evidence & references
deploy/README.md(tiers, profiles),deploy/helm/README.md(bundled vs external dependencies).