Deploy with Docker

The Busbar image is a FROM scratch container: the static binary and the provider catalog, nothing else (a few MB). It’s the fastest way to run Busbar on a single host.

1. Pull and verify

docker pull getbusbar/busbar:1.5.0

Verify the image’s build provenance before you trust it (the attestation binds the image digest to the release workflow):

gh attestation verify oci://index.docker.io/getbusbar/busbar:1.5.0 --repo GetBusbar/busbar

The GHCR mirror (ghcr.io/getbusbar/busbar) additionally carries a cosign signature.

2. Run on a single host

The provider catalog ships inside the image at /etc/busbar/providers.yaml, so you only mount your config.yaml. Provider keys come from the environment:

docker run -d --name busbar \
  -p 8080:8080 \
  -e ANTHROPIC_KEY \
  -v "$PWD/config.yaml:/etc/busbar/config.yaml:ro" \
  getbusbar/busbar:1.5.0

curl -s http://localhost:8080/healthz && echo ok

Pin an exact tag (getbusbar/busbar:1.5.0) in production rather than riding latest.

3. Docker Compose

Grab the reference file (curl -O https://getbusbar.com/compose.yaml) or copy it:

compose.yaml

services:
  busbar:
    image: getbusbar/busbar:1.5.0
    ports:
      - "8080:8080"
    environment:
      # Read from the host env or a .env file — never inline keys here.
      ANTHROPIC_KEY: ${ANTHROPIC_KEY}
      BUSBAR_ADMIN_TOKEN: ${BUSBAR_ADMIN_TOKEN}   # guards the admin API
    volumes:
      - ./config.yaml:/etc/busbar/config.yaml:ro
      # Durable store only: a writable volume for the sqlite store plugin.
      - busbar-data:/var/lib/busbar
    healthcheck:
      test: ["CMD", "/usr/local/bin/busbar", "--validate"]
      interval: 30s
      timeout: 5s
      retries: 3
    restart: unless-stopped

volumes:
  busbar-data:

docker compose up -d

Notes

• Admin plane. The admin API runs on its own listener (:8081), loopback by default, so it is not published by the -p 8080:8080 above. To manage it, publish :8081 only behind mTLS (admin_tls); a network-exposed admin bind refuses to boot without it. See the Admin API.
• Durable store. With the default store: memory, governance ledgers are ephemeral per-container and Busbar needs no volume. To persist keys and usage, configure a durable store plugin — e.g. store: { module: sqlite, settings: { db_path: /var/lib/busbar/governance.db } } — and mount a writable volume (busbar-data above). The cluster-shared postgres / redis store plugins need no local volume.
• Custom catalog. To add providers beyond the shipped catalog, mount your own providers.yaml over /etc/busbar/providers.yaml.
• Scaling / HA. With store: memory Busbar is stateless: run several containers (Compose deploy.replicas, or multiple hosts) behind a proxy that health-checks /healthz. For shared governance across replicas, use a cluster-shared store plugin (postgres / redis); note that requests/tokens rate windows are per-process (caps enforce per node), while budgets accrue to the shared store. See Running multiple instances (HA).