Skip to main content
Archil is an elastic, POSIX-compliant filesystem backed by object storage, with optional sync to your own S3, GCS, R2, or any S3-compatible bucket. Mount an Archil disk inside a Superserve sandbox to give it a fast workspace whose data persists across runs, survives the sandbox, and can be mounted by several sandboxes at once with --shared. Because every Superserve sandbox is a full Firecracker microVM, FUSE works inside the sandbox with no privileged-host workarounds, so you mount the disk with the same archil mount command you’d run on any Linux box.
Create a disk and a disk-scoped mount token in the Archil console first. Keep its region (e.g. aws-us-east-1) and disk reference handy: an owner-qualified name (myorg/my-disk) or ID (dsk-0123456789abcdef). See Archil’s docs for disk setup.

​
1. Bake the Archil client into a template

Install the Archil CLI and its libfuse2 dependency at build time so every sandbox starts ready to mount. Templates snapshot this, so each sandbox launches fast with nothing to reinstall. 
import { Template } from "@superserve/sdk"

const template = await Template.create({
  name: "archil-base",
  from: "ubuntu:22.04",
  steps: [
    { run: "apt-get update && apt-get install -y curl libfuse2" },
    { run: "curl -fsSL https://archil.com/install | sh" },
  ],
})

await template.waitUntilReady()

​
2. Mount the disk at runtime

Create a sandbox from the template, then run archil mount. Pass the disk-scoped token as a per-command env var so it’s present only for the mount itself, not for every process in the sandbox. 
import { Sandbox } from "@superserve/sdk"

const sandbox = await Sandbox.create({
  name: "archil-workspace",
  fromTemplate: "archil-base",
})

await sandbox.commands.run("mkdir -p /mnt/archil")
await sandbox.commands.run(
  "archil mount myorg/my-disk /mnt/archil --region aws-us-east-1",
  { env: { ARCHIL_MOUNT_TOKEN: process.env.ARCHIL_MOUNT_TOKEN! } },
)

// /mnt/archil is now a live, persistent Archil filesystem
await sandbox.files.write("/mnt/archil/notes.txt", "written from a sandbox")
const listing = await sandbox.commands.run("ls -la /mnt/archil")
console.log(listing.stdout)
Mounting needs root. Superserve runs commands as the template’s default user (root unless a user build step changed it), so the default template above mounts cleanly.

​
3. Flush and unmount before you kill

Archil replicates writes across availability zones before they return, and (when the disk is connected to your own bucket) syncs them there within a few minutes. Unmount before killing the sandbox to flush any in-flight writes cleanly. 
await sandbox.commands.run("archil unmount /mnt/archil")
await sandbox.kill()

​
Share one disk across many sandboxes

Add --shared to mount the same disk from several sandboxes at once. Every mount is strongly read-after-write consistent, so a write from one sandbox is immediately visible to the others. That makes it a fit for parallel-agent setups that build on shared state. 
await sandbox.commands.run(
  "archil mount myorg/my-disk /mnt/archil --region aws-us-east-1 --shared",
  { env: { ARCHIL_MOUNT_TOKEN: process.env.ARCHIL_MOUNT_TOKEN! } },
)

​
How it complements pause and resume

Pause and resume checkpoint one sandbox’s full VM state: memory, processes, and local disk. An Archil mount adds storage that lives outside any single sandbox: it survives kill(), can sync to your own object store, and can be mounted by other sandboxes concurrently. Use pause/resume to suspend a long-running job cheaply; use Archil for workspaces, caches, and datasets you want to share or keep beyond a sandbox’s life.
The mount token is a credential scoped to a single disk, so mint a dedicated one for sandbox use and pass it per-command, as shown above. For credentials your sandbox code uses to authenticate outbound requests, such as API keys, prefer secrets so the real value never enters the VM.