Docker Deployment

Containment Chamber publishes Docker images to GitHub Container Registry. The runtime image uses a scratch base: no shell or package manager, just the statically-linked binary and CA certificates.

Quick Run

Start a signer with a local config file and keystores directory:

docker run -d \
  --cap-add IPC_LOCK \
  -p 9000:9000 \
  -p 3000:3000 \
  -v ./config.yaml:/config.yaml:ro \
  -v ./keystores:/keystores:ro \
  ghcr.io/unforeseen-consequences/containment-chamber:latest \
  server -c /config.yaml

Port 9000 serves the signing API, and port 3000 exposes Prometheus metrics.

--cap-add IPC_LOCK lets the process call mlockall() so key material is not paged to swap. Without it, the signer still starts, but logs a warning that memory locking failed.

Docker Compose

Create a docker-compose.yml alongside your config.yaml and keystores/ directory:

services:
  containment-chamber:
    image: ghcr.io/unforeseen-consequences/containment-chamber:latest
    command: server -c /config.yaml
    ports:
      - "9000:9000"   # signing API
      - "3000:3000"   # metrics
    cap_add:
      - IPC_LOCK
    volumes:
      - ./config.yaml:/config.yaml:ro
      - ./keystores:/keystores:ro
    environment:
      CONTAINMENT_ANTI_SLASHING__URL: postgresql://cc:secret@postgres:5432/slashing
    restart: unless-stopped
    depends_on:
      postgres:
        condition: service_healthy

  postgres:
    image: postgres:16-alpine
    environment:
      POSTGRES_USER: cc
      POSTGRES_PASSWORD: secret
      POSTGRES_DB: slashing
    volumes:
      - postgres-data:/var/lib/postgresql/data
    healthcheck:
      test: ["CMD-SHELL", "pg_isready -U cc -d slashing"]
      interval: 5s
      timeout: 3s
      retries: 5

volumes:
  postgres-data:

Caution

Change the PostgreSQL password. Never use secret in production. Set POSTGRES_PASSWORD and the connection string in CONTAINMENT_ANTI_SLASHING__URL to a strong, unique password.

Configuration

Create a minimal config.yaml that works with the Compose setup above:

server:
  listen_address: "0.0.0.0"
  listen_port: 9000

metrics:
  listen_address: "0.0.0.0"
  listen_port: 3000

network: mainnet

key_sources:
  filesystem:
    paths:
      - /keystores

anti_slashing:
  backend: postgres
  # URL is injected via CONTAINMENT_ANTI_SLASHING__URL environment variable

The CONTAINMENT_ANTI_SLASHING__URL environment variable in the Compose file overrides the config file value, keeping the database credentials out of the config.

Environment Variables

All configuration options can be set via environment variables using the CONTAINMENT_ prefix. Use double underscores (__) to represent nesting in the YAML structure.

CONTAINMENT_SERVER__LISTEN_PORT=9001
CONTAINMENT_ANTI_SLASHING__BACKEND=postgres
CONTAINMENT_ANTI_SLASHING__URL="postgresql://cc:secret@postgres:5432/slashing"

Tip

Environment variables override values from the config file. This makes it easy to keep a base config in the image and customize per-environment with env vars.

Operations

# Start all services
docker compose up -d

# Watch signer logs
docker compose logs -f containment-chamber

# Check health
curl http://localhost:9000/upcheck

# List loaded validator keys
curl http://localhost:9000/api/v1/eth2/publicKeys

# Stop all services
docker compose down

# Stop and remove volumes (deletes slashing protection database)
docker compose down -v

Tip

The PostgreSQL backend supports multiple signer instances sharing the same database for slashing protection. To run multiple replicas, ensure all instances can access the same keystores and point to the same PostgreSQL database. Use docker compose up -d --scale containment-chamber=2 to test locally.

Image Tags

Tag	Description
latest	Latest stable release
vX.Y.Z	Pinned to a specific version

For production, pin to a specific version tag to avoid unexpected upgrades:

docker pull ghcr.io/unforeseen-consequences/containment-chamber:v1.0.0

Multi-Architecture

Images are built for both linux/amd64 and linux/arm64. Docker automatically pulls the correct architecture for your platform — this includes Apple Silicon Macs, AWS Graviton instances, and standard x86 servers.

Next Steps

• Kubernetes — scale to multiple replicas with Helm
• Production Hardening — lock down the container and network
• Observability — set up Prometheus metrics and log aggregation