Open source · MIT licensed · Alpha
Garrison is a self-hosted, multi-tenant control plane for Claude Code, Codex, Mux, Gemini CLI, and any command-line agent you describe with a harness profile. Your applications call agents over REST, MCP, or A2A. Workers you operate pull the work, run the harness, and stream the results back.
Garrison is alpha software. The API, MCP tools, schema, and SDKs can change between releases.
What it is
Coding and research agents like Claude Code and Codex are built to run in a terminal. Garrison turns them into services. You define an agent once, bind it to a harness, prompts, tools, and secrets, and then any application, script, or other agent can invoke it.
Every request goes through the same tenants, credentials, and role-based permissions. Every run is recorded: which deployment ran it, which prompt template versions it was compiled with, what the harness printed, what it cost, and who approved what along the way.
What it does
Garrison does not replace your agent. It handles configuration, access, dispatch, review, and history so the agent can be shared safely.
A profile describes the executable, argument templates, environment, files to write, how the prompt is delivered, the MCP config format, and which parser reads the output. Clone a built-in profile and edit it without a release.
System prompts, task wrappers, delegation instructions, and tool descriptions are versioned templates with a live preview. Each run records the exact versions it used.
A deployment ties an agent to a harness, prompts, MCP servers, secrets, a workspace, placement rules, and limits. Weights split traffic, so a Claude Code variant and a Mux variant can run side by side.
With delegation turned on, an agent gets a short-lived run token and can invoke the agents its policy allows, within depth limits and never with more permission than the person who started the chain.
Tool calls that need permission go to Garrison. Allow, deny, and ask rules settle most of them. The rest wait in an approvals inbox until someone decides, and a timeout denies by default.
Chain agents into stages. Each stage gets the previous result and artifacts, and a stage can stop for a person to approve it, send it back with feedback, or reject it.
Start agents or pipelines on a cron schedule or from an HMAC-signed webhook. Garrison posts signed notifications to your endpoints when runs finish, fail, or wait for approval.
Tenants, users, credentials, roles, scoped role assignments, encrypted secrets, audit records, and request history. Cross-tenant reads return 404.
See why a run can or cannot be placed, track queue and execution time, and follow runs through Prometheus metrics, OpenTelemetry traces, logs, and Grafana dashboards.
How it works
The control plane decides what runs and how. Workers only make outbound connections, never touch the database, and run exactly what they are handed.
Over REST, MCP, or A2A. Garrison checks the caller's permission to execute that agent, picks one of its deployments by weight, validates any parameter overrides, and stores the run as queued.
Workers long-poll for work. A claim is an atomic compare-and-set that bumps a fencing epoch, so two workers can never both own a run.
It resolves the full command line, environment, files, stdin, parser, timeouts, and MCP servers into an ExecutionSpec, and mints a run token if the agent uses Garrison tools. The worker never renders a template.
It prepares the workspace, checks MCP servers before launch, starts the harness, and sends parsed events back in batches. Callers watch them live over SSE or WebSocket.
The result is stored, the run token is revoked, and the run shows up in transcripts and analytics. If a worker dies, its lease expires, the leader requeues or fails the run, and a stale worker that returns is fenced out by its old epoch.
Use cases
Give your product or internal tools a Claude Code or Codex agent they can call with one request, with workspaces, secrets, and limits set by the operator instead of the caller.
Publish a reviewer, a researcher, and a writer as separate agents, and let an orchestrator delegate to them. The run tree shows who called whom and what each one returned.
Draft, review, and revise in pipeline stages, with a person approving or sending work back between stages, and risky tool calls held for approval.
Run a nightly report on a cron schedule, or start an agent from a signed webhook when a ticket opens, and get a signed notification when it finishes.
Operate one set of workers for many tenants. Each tenant keeps its own agents, secrets, permissions, and run history, and scheduling weights keep one tenant from crowding out the rest.
Put two deployments of the same agent on different harnesses or models, split traffic by weight, and compare time to first token, cost, and outcomes on the Analytics page.
Benefits
Harness profiles, prompts, and deployments are configuration. Swap a model, a tool, or the whole harness and the integration calling the agent stays the same.
REST, MCP, and A2A share tenants, credentials, roles, and audit. You do not maintain separate access rules per protocol.
Workers pull work over outbound connections and never see the database. Run them on a laptop, a VM, or as a StatefulSet, and use per-run Kubernetes pods for untrusted work.
Control-plane replicas and workers scale independently. PostgreSQL holds shared state for multi-replica installs, and any replica can serve any client.
Exact template versions, events, transcripts with secret redaction, cost, approvals, and the effect journal are all recorded, so you can answer what happened and why.
MIT licensed and self-hosted. Your harness credentials are stored as encrypted tenant secrets, never as worker environment variables.
Getting started
Docker Compose is the quickest way to see Garrison work. Kubernetes adds per-run pod isolation and cluster deployment. Every option seeds tenant default with administrator admin@garrison and generates a random password; there is no default password.
You need Docker with Compose v2, about 10 GB of free disk, and 8 GB of memory allocated to Docker to start. The stack runs a control plane, two workers, PostgreSQL, the dashboard, and Prometheus, Grafana, Tempo, Loki, and Alloy.
$ git clone https://github.com/jchristn/Garrison && cd Garrison/docker
$ ./update.sh # generates keys into .env, builds the images, starts the stack; Windows: update.batOpen http://127.0.0.1:8080 and sign in with the administrator password update.sh printed. It is also GARRISON_ADMIN_PASSWORD in docker/.env, where optional harness credentials (Claude, Codex, Mux) and ports go too.
| Service | Address |
|---|---|
| Dashboard | http://127.0.0.1:8080 |
| REST and A2A | http://127.0.0.1:8700 |
| MCP | http://127.0.0.1:8701/mcp |
| PostgreSQL | 127.0.0.1:5433 |
| Grafana | http://127.0.0.1:3000 |
Local clusters need kubectl, openssl, and Docker to build the images. The scripts build the images, generate secrets, apply the overlay, and wait for every rollout. The local overlays run one server, two workers, the dashboard, PostgreSQL, and a bootstrap Job in namespace garrison.
$ git clone https://github.com/jchristn/Garrison && cd Garrison
$ brew install k3d # or see https://k3d.io for other platforms
$ k3d cluster create garrison --api-port 127.0.0.1:6550 -p "127.0.0.1:8080:80@loadbalancer"
$ K3D_CLUSTER=garrison k8s/scripts/deploy-k3s.sh --build$ k8s/scripts/deploy-k3s.sh --build$ export ANTHROPIC_API_KEY=... # optional, any of the harness variables
$ k8s/scripts/deploy-minikube.sh$ k8s/scripts/smoke-test.sh # invokes a fake-harness agent and checks it succeeds
$ k8s/scripts/port-forward.sh # REST, MCP, and dashboard on 127.0.0.1:8700, 8701, and 8080
$ kubectl -n garrison get secret garrison-secrets -o jsonpath='{.data.admin-password}' | base64 --decode; echoThe smoke test needs no model credentials. Sign in at http://127.0.0.1:8080 as admin@garrison in tenant default.
The production overlay expects a managed PostgreSQL and a TLS certificate. It runs three control-plane replicas spread across zones and nodes, an HPA from two to ten replicas, disruption budgets, four workers with 50 GiB workspaces, and an ingress-nginx Ingress with TLS.
garrison-db with keys host, port, database, username, and password.garrison-tls for your host name, for example with cert-manager.garrison.example.com in overlays/production/ingress.yaml.kustomize edit set image or an images: block in your own overlay. Never deploy latest.$ k8s/scripts/generate-secrets.sh
$ kubectl apply -k k8s/overlays/productionThe chart in k8s/helm/garrison renders the same resources and expects the same Secrets. It ships values-minikube.yaml, values-k3s.yaml, and values-production.yaml to match the overlays.
$ k8s/scripts/generate-secrets.sh
$ helm install garrison k8s/helm/garrison -n garrison -f k8s/helm/garrison/values-k3s.yaml --set smokeTest.enabled=true
$ helm test garrison -n garrisonMCP clients use https://<your host>/mcp. Multiple control-plane replicas need PostgreSQL; the server refuses to start on SQLite when more than one replica is expected.
The quick start picks up from any running stack. It stores your harness credentials as secrets, applies a sample set of agents on Claude Code, Codex, and the fake harness (one allowed to delegate to the others), and calls each of them over REST, MCP, and A2A. No provider account? The echo agent and the fake-harness smoke test work without one.
Talk with us on Discord, or open an issue on GitHub.