Kubernetes

There are no official Helm charts yet. Docker Compose is the supported install path, and the compose file is the reference for what a correct deployment looks like. That said, the stack is a conventional shape — three stateless services in front of Postgres and Redis — and translates to Kubernetes without surprises. This page is the map.

Images

Every release publishes multi-arch images to GitHub Container Registry:

ghcr.io/specbench-io/specbench-api
ghcr.io/specbench-io/specbench-web
ghcr.io/specbench-io/specbench-mcp

Pin a version tag, and run all three at the same version — they release as one unit. Building from the repository instead works too; note the build contexts (the API builds from its own directory; web and MCP build from the repo root so the build can see the workspace packages they depend on):

docker build -t <registry>/specbench-api  apps/specbench-api
docker build -t <registry>/specbench-web  -f apps/specbench-web/Dockerfile .
docker build -t <registry>/specbench-mcp  -f apps/specbench-mcp/Dockerfile .

The services

Workload	Kind	Notes
`api`	Deployment	All state lives behind it. Runs migrations on startup.
`web`	Deployment	nginx serving static files; stateless, scale freely.
`mcp`	Deployment	Needs `SPECBENCH_API_URL` pointing at the API Service.
`postgres`	StatefulSet	Or a managed database — the only durable store.
`redis`	Deployment	Ephemeral by design; `--requirepass`, `noeviction`. No volume.

The API takes its configuration from the environment — connection strings, identity, CORS, and the optional GitHub App — exactly as described in Configuration. Put secrets in a Secret and mount them as env vars; the settings are ordinary ASP.NET Section__Key names.

Routing

The web image's nginx proxies /api/ to http://api:8080 — the compose service name. On Kubernetes, either:

name the API Service api (port 8080) in the same namespace, and the web image works unchanged; or
route /api at the Ingress straight to the API Service, bypassing the in-pod proxy.

Either way the browser must see web and API on one origin — that's the assumption the app is built on. Expose the MCP service (port 8081) wherever suits; agents reach it directly with a bearer token, so it doesn't need to share the web origin. The API uses SignalR for realtime, so the route to it must allow WebSocket upgrades (most Ingress controllers do by default).

Replicas

web and mcp scale horizontally without ceremony.
api: more than one replica requires every replica to share the ASP.NET data-protection key ring — otherwise flows that round-trip signed state (like the GitHub App install) break intermittently. Start with one replica; scale only once the key ring is on shared storage.

Postgres and Redis

Postgres is the whole of your durable state — treat it accordingly (volume, backups, or hand it to a managed service). Redis is coordination only: losing it loses nothing, so an in-cluster Deployment with no volume is correct, not a shortcut. Keep noeviction — evicting coordination state under memory pressure is worse than refusing writes.

Helm charts

Official charts are on the roadmap. If you build your own in the meantime, the compose file is the contract worth encoding — and contributions are welcome on GitHub.