Skip to main content

Dev container images

The full development stack is docker-compose.infra.yml (MongoDB + Redis + RustFS) plus docker-compose.dev.yml (backend with AIR + both frontends with Vite HMR). The backend dev image is built locally from docker/Dockerfile.dev-backend — no registry auth required.

:::note ADR-0006 The old two-flavor split (docker-compose.dev-public.yml vs docker-compose.dev.yml, selected by DEV_COMPOSE_VARIANT) was removed when Orkestra collapsed to a core-only base. There is now one dev compose file, on public images by default, with Chainguard as a per-fork build-arg override. See ADR-0006. :::

The dev backend image​

docker-compose.dev.yml builds docker/Dockerfile.dev-backend:

ARG GO_BASE=golang:1.25.10-alpine
FROM ${GO_BASE}
RUN apk add --no-cache git build-base \
 && GOBIN=/usr/local/bin go install github.com/air-verse/air@latest \
 && rm -rf /root/.cache /go/pkg
WORKDIR /app
  • Default: public golang:1.25.10-alpine from Docker Hub — no auth, fork-friendly. AIR is pre-baked so the container starts as a non-root user without a runtime go install.
  • Frontends: node:24-alpine (both the operator console and the Tier-2 client SPA).

Chainguard override (optional)​

A fork with a Chainguard dhi.io subscription can build the backend on a hardened base via the GO_BASE build-arg:

docker compose -f docker-compose.dev.yml build \
  --build-arg GO_BASE=dhi.io/golang:1 orkestra-backend

(A non-Alpine base may need the apk line in Dockerfile.dev-backend adapted.)

Staging and production​

docker-compose.staging.yml and docker-compose.prod.yml are unchanged by this — one app file per environment. See docker/CLAUDE.md for the full Docker guide.