Skip to main content

​
Requirements

  • macOS with OrbStack, or any Docker engine
  • Go 1.25+ to build locally — or skip it and use make build-docker, which compiles inside a container

​
Install

1

Build and install the CLI

Builds a binary for your host and copies it to /usr/local/bin (prompts for sudo). Override the destination with PREFIX=~/.local make install.
2

Build the container images

Builds airlock/base (the sandbox, with agents and MCP servers preinstalled) and airlock/proxy (the egress gate).You can rebuild them later with airlock build, but an installed binary cannot find the source tree on its own. Point it at the checkout: AIRLOCK_SRC=~/code/Airlock airlock build.
3

Start the backend

Brings up the self-hosted backend — Postgres plus airlockd, which serves both the ingest API and the console on localhost:4747. This is where airlock publish ships events; the backend migrates its own database, so there is no schema to create. See deploy.
4

Sign in

Prompts for the backend URL, your email, and your password (your admin creates the account in the console). It caches an ingest-scoped API token in ~/.airlock/auth.json, so sessions and published events are attributed to you.
5

Give the agent your API key

Recognized keys are copied into the sandbox. ANTHROPIC_API_KEY, OPENAI_API_KEY, OPENROUTER_API_KEY, and XAI_API_KEY are passed through by default — see configuration.

​
Open a sandbox

Or run an agent directly, without dropping into a shell first:
Inside the sandbox:
  • The repo is mounted read-write at /<reponame>, which is also the working directory.
  • The host home directory, ~/.ssh, ~/.aws, and other repos are absent.
  • All network traffic is forced through the repo’s Airlock proxy. Out of the box it allowlists (model APIs work, everything else gets a 403); switch it to a blocklist when you would rather not gate the team — see choosing a mode.
  • Every connection attempt is logged to ~/.airlock/logs/<repo>/audit-<date>.jsonl, stamped with your user id, the repo, and timing/byte counts.

​
Open up the network

By default the agent can reach the model APIs (api.anthropic.com, api.openai.com, openrouter.ai, api.x.ai) and the Claude Code auth and config hosts (claude.com, claude.ai) — nothing else. Two ways to give it more:
Add the specific host it needs:
.airlock.toml
Or flip the repo to blocklist mode — everything reachable except what you name, still fully logged:
.airlock.toml
The proxy restarts with each airlock run, so either change takes effect the next time you start a sandbox. See choosing a mode for when each fits.

​
Add an internal system

Give the agent scoped access to Notion or Confluence:
It prompts for credentials, stores them outside the repo, allowlists just that connector’s domain, and registers the server so airlock claude picks it up. See MCP connectors.

​
Review what it did

The egress log records every host the sandbox reached. To see the conversation itself (and to tie both to a person) you publish to the backend, then open the console it serves:
Publishing requires airlock login first; the console has its own login, and non-admin accounts see their own activity only. See audit log for what gets shipped and retained, and console for what the UI shows.

​
Tear down

Sandbox containers are removed automatically when a session exits; airlock stop cleans up the repo’s proxy and is safe to run when there is nothing to remove. The backend keeps running independently — stop it with docker compose -f deploy/docker-compose.yml down (see deploy).