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

# Mount in a container

Containers lose all local data when they stop unless you configure external storage. Mounting an Archil disk gives the processes inside the container a persistent, elastic POSIX filesystem backed by S3 — no EBS snapshots, no manual volume provisioning, no object-storage SDKs.

The best way to get access to Archil in a container depends on your runtime:

| Runtime                                                                          | Recommended                                                                                                                                                  |
| -------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------ |
| **Docker / Podman / OCI containers** sharing the host kernel                     | [**Bind mount from the host**](#bind-mount-from-the-host) — simpler, no privileged containers, and avoids the seccomp pitfalls of FUSE-inside-the-container. |
| **MicroVMs** (Firecracker, Cloud Hypervisor, Kata, gVisor) with isolated kernels | [**FUSE inside the microVM**](#fuse-inside-the-container) — there's no host FUSE mount to bind from, so the VM mounts Archil itself.                         |
| **Kubernetes**                                                                   | Use the [Archil CSI driver](/reference/csi-driver). It manages Archil mounts as native persistent volumes without privileged pods.                           |
| **Sandbox platforms** (Daytona, e2b)                                             | Use the provider's built-in Archil integration — see [Sandbox providers](#sandbox-providers).                                                                |

## Bind mount from the host

First, install the `archil` CLI and mount a disk on the host:

```bash theme={null}
curl -s https://archil.com/install | sh

sudo mkdir -p /mnt/archil
export ARCHIL_MOUNT_TOKEN="<token>"
sudo --preserve-env=ARCHIL_MOUNT_TOKEN archil mount <disk-name> /mnt/archil --region aws-us-east-1
```

Then start the container with a volume mount:

```bash theme={null}
docker run -v /mnt/archil:/data myimage
```

The application inside the container reads and writes to `/data` as a normal filesystem. Archil handles caching on fast local SSD and synchronizing to S3 in the background.

### Docker Compose

```yaml theme={null}
services:
  app:
    image: myimage
    volumes:
      - /mnt/archil:/data
```

You can manage delegations from inside the container by installing the Archil client there too:

```bash theme={null}
archil checkout /data/my-file.txt
```

## FUSE inside the container

Some runtimes don't share the host's kernel — most commonly microVMs like [Firecracker](/guides/virtualization/firecracker), Cloud Hypervisor, Kata Containers, or gVisor. In principle you could share the host's FUSE mount into the guest over **virtio-fs**, but virtio-fs support across microVM runtimes is spotty — some implementations don't support it at all, others lag on features like extended attributes, locking, or large-file I/O, and performance varies widely. It's simpler and more portable to have the guest mount Archil itself.

Install the Archil client in the guest image and run `archil mount` during boot or as part of your workload's entrypoint:

```bash theme={null}
curl -s https://archil.com/install | sh
mkdir -p /mnt/archil
archil mount <disk-name> /mnt/archil --region aws-us-east-1
```

For a standard Docker container sharing the host kernel, doing this requires `--privileged` (or `SYS_ADMIN`) plus `/dev/fuse`:

```bash theme={null}
docker run --privileged --device /dev/fuse \
  -e ARCHIL_MOUNT_TOKEN="<token>" \
  myimage
```

<Warning>
  Running an OCI container with `--privileged` grants full host access and exposes the mount to the host's seccomp policies — some operations (e.g. executing a binary from the disk) can fail with `EACCES`. If you're on Docker/Podman, use the [bind-mount approach](#bind-mount-from-the-host) above. `--privileged` is only the right answer for microVMs that don't share the host kernel.
</Warning>

## Kubernetes

For production Kubernetes deployments, use the [Archil CSI driver](/reference/csi-driver). It manages Archil mounts as native Kubernetes persistent volumes, so pods get Archil storage without privileged containers or host mounts.

## Sandbox providers

Some managed sandbox and dev-environment platforms support mounting Archil disks natively. On these platforms, follow the provider's guide rather than the manual steps above:

* [**Daytona** — Mount an Archil disk](https://www.daytona.io/docs/en/mount-external-storage/#mount-an-archil-disk)
* [**e2b** — Archil storage](https://e2b.dev/docs/storage/archil)

## Command reference

For every flag `archil mount`, `archil unmount`, and the rest of the `archil` CLI accept, see the [`archil` CLI reference](/reference/archil-cli).