> ## Documentation Index
> Fetch the complete documentation index at: https://docs.try-airlock.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Quickstart

> Install Airlock, start the backend, and open your first sandboxed shell.

## Requirements

* macOS with [OrbStack](https://orbstack.dev), or any Docker engine
* Go 1.25+ to build locally — or skip it and use `make build-docker`, which
  compiles inside a container

## Install

<Steps>
  <Step title="Build and install the CLI">
    ```sh theme={null}
    make install
    ```

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

  <Step title="Build the container images">
    ```sh theme={null}
    make 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`.
  </Step>

  <Step title="Start the backend">
    ```sh theme={null}
    docker compose -f deploy/docker-compose.yml up -d
    ```

    Brings up the self-hosted backend — Postgres plus `airlockd`, which
    serves both the ingest API and the [console](/dashboard) 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](/deploy).
  </Step>

  <Step title="Sign in">
    ```sh theme={null}
    airlock login
    ```

    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.
  </Step>

  <Step title="Give the agent your API key">
    ```sh theme={null}
    export ANTHROPIC_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](/configuration#env).
  </Step>
</Steps>

## Open a sandbox

```sh theme={null}
cd ~/code/some-repo
airlock                # jailed shell: agent@some-repo:~$
```

Or run an agent directly, without dropping into a shell first:

```sh theme={null}
airlock claude
```

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](/configuration#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:

```sh theme={null}
airlock init           # writes an example .airlock.toml
```

Add the specific host it needs:

```toml .airlock.toml theme={null}
[network]
allow = ["registry.npmjs.org"]
```

Or flip the repo to blocklist mode — everything reachable except what you
name, still fully logged:

```toml .airlock.toml theme={null}
[network]
mode  = "blocklist"
block = ["pastebin.com", "gist.github.com"]
```

The proxy restarts with each `airlock` run, so either change takes effect the
next time you start a sandbox. See
[choosing a mode](/configuration#choosing-a-mode) for when each fits.

## Add an internal system

Give the agent scoped access to Notion or Confluence:

```sh theme={null}
airlock setup mcp
```

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](/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:

```sh theme={null}
airlock publish        # transcripts + proxy egress → the backend
open http://localhost:4747     # the console: sign in, read the timeline
```

Publishing requires `airlock login` first; the console has its own login,
and non-admin accounts see their own activity only. See
[audit log](/audit-log) for what gets shipped and retained, and
[console](/dashboard) for what the UI shows.

## Tear down

```sh theme={null}
airlock stop           # remove this repo's proxy container
```

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](/deploy)).