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

# Getting started

> Create a Bunker, choose who holds its keys, and connect to it.

A **Bunker** is a persistent, hardened confidential cloud computer for you or your agents to use. It runs in an enclave using Tinfoil's runtime, and comes with an encrypted workspace disk and an expansive set of software preinstalled. Tinfoil cannot see inside it, and you can only connect with keys that are bound to its attestation.

The Bunker's **Perimeter** is the only way for it to reach the outside world. A Perimeter is a second enclave that holds your credentials, and can set fine-grained policies on what the Bunker can reach. One Perimeter can serve multiple Bunkers. This lets agents perform actions without ever accessing any access-control compromising secrets.

This page walks you through creating both, connecting, and choosing where keys live.

## Prerequisites

* A Tinfoil account with Bunkers enabled. If **Bunkers** does not appear in the [dashboard](https://dash.tinfoil.sh), [contact us](mailto:contact@tinfoil.sh).
* A browser that supports passkeys, unless you plan to [bring your own key](#bring-your-own-key).
* The [Tinfoil CLI](https://docs.tinfoil.sh/sdk/cli-sdk.md) to connect over SSH. The web terminal needs only the browser.

## Create a Bunker in the dashboard

Go to [**Bunkers**](https://dash.tinfoil.sh/?tab=sandboxes) in the dashboard and choose **Get started**. The first Bunker also creates its Perimeter. Later, choose **Add bunker** on an existing Perimeter, or **Add Perimeter** to create another one.

Choose **Synced with your passkey** for browser access and use across computers. Choose **CLI only** if you want to manage private keys that are managed entirely on your own computer. See [Bring your own key](#bring-your-own-key).

## Connect

Once a Bunker is running, choose **Open in browser** to connect through a [web terminal](https://docs.tinfoil.sh/bunkers/features.md#web-terminal), or connect from your own terminal:

```bash theme={"dark"}
# Copy your synced keys to this computer
tinfoil login --sync

# Verify the Bunker, unlock its workspace, and install an SSH profile
tinfoil attest-ssh my-bunker --install

# Connect to the sandbox
ssh my-bunker
```

`attest-ssh` checks the attestation of both the Perimeter and the Bunker on your computer before sending any key, then pins the Bunker's attested SSH host key in `~/.ssh/tinfoil/my-bunker.conf`. Each boot gets a new host key, so run it again after the Bunker or its Perimeter restarts.

You log in to the Bunker as the `sandbox` user with passwordless `sudo` enabled. Your files live in `/workspace`, with your home directory persisted by default on the encrypted volume.

## Provisioning with the CLI

The CLI creates the same resources as the dashboard. Both commands require `--tag`, the published release to run; `tinfoil repo build info <owner/repo>` lists them for `tinfoilsh/confidential-agent-monitor` (Perimeter) and `tinfoilsh/confidential-agent-sandbox` (Bunker).

```bash theme={"dark"}
tinfoil login --sync

tinfoil perimeter create work --tag <PERIMETER_RELEASE>
tinfoil bunker create my-bunker --tag <BUNKER_RELEASE> --perimeter work --workspace-size 16

tinfoil attest-ssh my-bunker --install
ssh my-bunker
```

`--perimeter` is required only when you have more than one Perimeter. Workspace sizes are 2, 4, 8, 16, 32, or 64 GB. To keep data from an earlier Bunker, pass `--workspace <VOLUME>` with an unattached workspace volume instead of a size.

Day-to-day lifecycle:

| Command | What it does |
| - | - |
| `tinfoil bunker status [name]` | List Bunkers, or show one with its connection instructions |
| `tinfoil bunker start <name>` | Boot a stopped Bunker, unlock its workspace, and refresh its SSH profile |
| `tinfoil bunker restart <name>` | Stop and boot again, then unlock |
| `tinfoil bunker stop <name>` | Stop the VM and keep the workspace |
| `tinfoil bunker delete <name>` | Delete the Bunker and its workspace volume |
| `tinfoil perimeter stop <name>` | Stop a Perimeter together with its Bunkers |
| `tinfoil perimeter delete <name>` | Delete a Perimeter, its Bunkers, and their workspaces |

A Perimeter is stopped and deleted together with its Bunkers, because they have no network without it. To keep a workspace while deleting its Bunker, stop the Bunker and run `tinfoil volume detach <VOLUME>` first.

## Bring your own key

Bunker trust comes from its **owner public key** saved into the measured image at launch time. The only way a sandbox can be accessed is that key. You can choose to manage this key on your own terms.

**In the dashboard**, choose **CLI only** under **Owner keys** and paste an `ssh-ed25519 AAAA…` public key on the key setup page.

**With the CLI**, pass your public key at creation:

```bash theme={"dark"}
tinfoil perimeter create work --tag <PERIMETER_RELEASE> --owner-public-key ~/.ssh/id_ed25519.pub
tinfoil bunker create my-bunker --tag <BUNKER_RELEASE> --owner-public-key ~/.ssh/id_ed25519.pub
```

The private key stays entirely in `ssh-agent`, and the first time you open the resource, the CLI generates its storage keys and saves them under `~/.tinfoil/resources/`, printing the exact path.

> [!WARNING]
>
> Back up the key file the CLI names. It holds the disk key for the workspace, without it the workspace data is lost.

A Perimeter created with your own key accepts only Bunkers that also use your own key.

### Web dashboard vs `tinfoil perimeter open`

Two different programs can hold your keys while you manage a Perimeter. The difference is what you trust.

**Synced with your passkey.** Your browser generates the keys on `terminal.tinfoil.sh` and encrypts them into a bundle (using a WebAuthn PRF). Tinfoil stores the encrypted bundle to provide cloud sync. When you open the Perimeter's settings or a web terminal, that page decrypts the keys in memory, verifies the Perimeter's attestation, and talks to the enclave over an end-to-end encrypted channel. This is convenient, but you trust the JavaScript that `terminal.tinfoil.sh` serves each time you load it. A modified page could misuse your keys after you unlock them.

**`tinfoil perimeter open`.** The CLI verifies the Perimeter's attestation on your computer, unlocks it over attested SSH, and forwards the Perimeter's own measured web interface to a local address such as `http://127.0.0.1:PORT/app/`. Your browser shows the interface, but the owner credentials stay in the CLI process. You trust the CLI binary you installed rather than a page served on each visit.

```bash theme={"dark"}
tinfoil perimeter open work
```

Keep the command running while you use the interface. It also restores connectivity for that Perimeter's Bunkers on this computer.

| | Synced with your passkey | CLI only |
| - | - | - |
| Where private keys live | Encrypted bundle at Tinfoil, opened in your browser or a synced CLI | Only on your computer |
| Browser access | Web terminal and hosted Perimeter settings | Perimeter settings through `tinfoil perimeter open` |
| New computer | `tinfoil login --sync` | Copy your SSH key and the saved storage key files yourself |
| Code you trust with keys | `terminal.tinfoil.sh` page and the CLI | The CLI only |

## Next steps

> [card] [Bunker features](https://docs.tinfoil.sh/bunkers/features.md)
>
> Coding agents, the web terminal, and the remote desktop.

> [card] [Perimeters](https://docs.tinfoil.sh/bunkers/perimeters.md)
>
> Connectors, credential substitution, and MCP tool pinning.

> [card] [Security](https://docs.tinfoil.sh/bunkers/security.md)
>
> The root of trust and the threat model.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.