Snapshot Your Agents: Configure Once, Deploy Instantly

Provisioning an AI agent sandbox takes time. You install system packages, pull the agent runtime, configure dependencies, set up services. For something like Hermes Agent, that's Python, Node, UV, a git clone, a virtual environment, and a full pip install of heavy ML dependencies. It works, but it takes minutes — and doing it again for every new sandbox is wasteful.

Clawstainer's snapshot feature solves this. Set up your environment once, save the configured state as a snapshot, and launch future sandboxes from that snapshot with everything already in place. No re-provisioning, no re-downloading, no waiting for apt-get. Boot to a fully configured agent in 2-3 seconds.

This post walks through the full workflow — both hands-on CLI commands and the automated agent provisioning path.

How Snapshots Work Under the Hood

Clawstainer uses OverlayFS to layer sandbox filesystems. When you create a sandbox, it gets a read-only base image (Ubuntu 24.04) and a writable upper layer where all your changes land — installed packages, config files, scripts, everything.

When you snapshot a sandbox, Clawstainer tars that upper layer into a compressed archive. When you create a new sandbox from that snapshot, it inserts the snapshot as a middle layer between the base image and a fresh writable layer:

┌─────────────────────────────────────────────┐ │ New Writable Layer (empty, yours to modify) │ ← top ├─────────────────────────────────────────────┤ │ Snapshot Layer (read-only) │ ← your provisioned state ├─────────────────────────────────────────────┤ │ Base Image (read-only, shared) │ ← Ubuntu 24.04 └─────────────────────────────────────────────┘

Each new sandbox gets its own writable layer on top. Changes in one sandbox never affect the snapshot or any other sandbox. The snapshot itself is only extracted once and cached — spin up ten sandboxes from the same snapshot and they all share the same read-only middle layer.

The CLI Workflow: Hands-On

Here's the direct approach. You create a sandbox, configure it however you want, snapshot it, and stamp out clones.

1. Create and provision a base sandbox

# Create a sandbox — use 4GB for Hermes (heavy Python deps), 2GB for OpenClaw
clawstainer create --name hermes-base --memory 4096 --cpus 2 --linger

# Provision with the built-in Hermes template
clawstainer provision <id> --components hermes-agent

The hermes-agent component handles everything: installs curl, git, xz-utils, runs the upstream install script (which pulls Python 3.11 via UV, clones the repo, creates a venv, installs all dependencies), and creates a wrapper script at /usr/local/bin/hermes-agent.

For OpenClaw, same idea but lighter:

clawstainer create --name openclaw-base --memory 2048 --cpus 2 --linger
clawstainer provision <id> --components openclaw

2. Verify it works

Before snapshotting, make sure the agent actually runs:

# Hermes
clawstainer exec <id> "hermes-agent --help"

# OpenClaw
clawstainer exec <id> "openclaw --version"

You can also shell in and do additional configuration — install extra tools, drop config files, set environment variables. The snapshot captures everything in the writable layer, not just installed packages.

# Shell in for manual tweaks
clawstainer shell <id>

# Install extra tools
apt-get install -y jq ripgrep htop

# Drop a config file
cat > /root/.config/hermes/settings.json << 'EOF'
{
  "model": "claude-sonnet-4-20250514",
  "temperature": 0.7
}
EOF

# Exit the shell
exit

All of that — the packages, the config file, the directory structure — gets captured in the snapshot.

3. Snapshot the configured state

# Snapshot with a descriptive name
clawstainer snapshot create <id> --name hermes-ready

# Check it
clawstainer snapshot list

Snapshots are stored as compressed tarballs at /var/lib/clawstainer/snapshots/ inside the host (or Lima VM on macOS). A fully provisioned Hermes snapshot is around 1GB; OpenClaw is around 700MB.

4. Launch new sandboxes from the snapshot

# Instant — no re-provisioning
clawstainer create --name worker-1 --from hermes-ready --memory 4096 --cpus 2 --linger
clawstainer create --name worker-2 --from hermes-ready --memory 4096 --cpus 2 --linger
clawstainer create --name worker-3 --from hermes-ready --memory 4096 --cpus 2 --linger

Each of those boots in 2-3 seconds with Hermes already installed, the venv populated, and the wrapper script in place. No waiting for pip, no re-cloning repos. The snapshot layer is read-only and shared; each sandbox gets its own writable layer for any future changes.

Verify they all work:

clawstainer exec worker-1 "hermes-agent --help"
clawstainer exec worker-2 "hermes-agent --help"
clawstainer exec worker-3 "hermes-agent --help"

5. Manage your snapshots

# List all snapshots with sizes and dates
clawstainer snapshot list

# Delete a snapshot you no longer need
clawstainer snapshot delete hermes-ready

The Agent Provisioning Workflow

If you're building agent infrastructure — deploying multiple agents for a team, a family, or a fleet of workers — the snapshot workflow becomes the foundation of your deployment pipeline.

Golden image pattern

Create one "golden" sandbox per agent type, provision it, validate it, snapshot it. Then deploy all future agents from that snapshot. Update the golden image when you need to upgrade the agent version or change the base configuration.

┌─────────────┐ ┌──────────────┐ ┌──────────────────┐ │ Create │ ──▸ │ Provision │ ──▸ │ Validate │ │ base box │ │ + configure │ │ (exec, shell) │ └─────────────┘ └──────────────┘ └────────┬─────────┘ │ ┌────────▾─────────┐ │ Snapshot │ │ "agent-ready" │ └────────┬─────────┘ │ ┌──────────────────────────────┼──────────────────────────────┐ │ │ │ ┌───────▾────────┐ ┌───────▾────────┐ ┌───────▾────────┐ │ --from │ │ --from │ │ --from │ │ agent-ready │ │ agent-ready │ │ agent-ready │ │ (2-3 seconds) │ │ (2-3 seconds) │ │ (2-3 seconds) │ └────────────────┘ └────────────────┘ └────────────────┘

Deploying a team or family from snapshots

Say you've built two golden images — hermes-ready for power users and openclaw-ready for everyone else. Now deployment is just a list of create --from commands:

# Power users get Hermes
clawstainer create --name dev-1 --from hermes-ready --memory 4096 --cpus 2 --linger
clawstainer create --name dev-2 --from hermes-ready --memory 4096 --cpus 2 --linger

# Everyone else gets OpenClaw
clawstainer create --name support-1 --from openclaw-ready --memory 2048 --cpus 2 --linger
clawstainer create --name support-2 --from openclaw-ready --memory 2048 --cpus 2 --linger
clawstainer create --name support-3 --from openclaw-ready --memory 2048 --cpus 2 --linger

Five agents, two types, all up in under 15 seconds total. Each one isolated, each one independent, each one ready to personalize.

Updating a golden image

When the upstream agent releases a new version, you don't re-provision every sandbox. You update the golden image and re-snapshot:

# Create a fresh base, provision with the latest version
clawstainer create --name hermes-base-v2 --memory 4096 --cpus 2 --linger
clawstainer provision <id> --components hermes-agent

# Validate
clawstainer exec <id> "hermes-agent --help"

# Replace the old snapshot
clawstainer snapshot delete hermes-ready
clawstainer snapshot create <id> --name hermes-ready

# New sandboxes now get the updated version
clawstainer create --name dev-3 --from hermes-ready --memory 4096 --cpus 2 --linger

Existing sandboxes keep running on the old version. New sandboxes get the update. No downtime, no in-place upgrades that can break things.

What Gets Captured

A common question: does the snapshot only capture installed packages, or does it capture files too?

It captures everything. The snapshot is a tar of the OverlayFS upper directory, which contains every filesystem change since the sandbox was created. That means:

Installed packages (apt-get install, pip install, npm install)
Config files you wrote or modified
Scripts and binaries you placed anywhere in the filesystem
Systemd services you created and enabled
User directories, dotfiles, shell history
Cloned repos and their contents
Virtual environments with all their site-packages

If you changed it, the snapshot has it.

Memory Requirements

One thing to watch: some agents have heavy dependencies that need significant memory during installation. Hermes Agent in particular pulls in packages like ctranslate2 and other ML libraries that spike memory usage during pip install.

Agent	Min Memory (provision)	Min Memory (runtime)	Snapshot Size
OpenClaw	2GB	1-2GB	~700MB
Hermes Agent	4GB	2-4GB	~1GB
Claude Code	2GB	1-2GB	~500MB

Hermes will OOM during provisioning if you give it less than 4GB. Once provisioned and snapshotted, you can run the resulting sandboxes with less memory if the workload allows — but give it 4GB during the initial install.

Exporting Snapshots

Snapshots live inside the host (or Lima VM on macOS) at /var/lib/clawstainer/snapshots/. If you want to back them up, share them with a teammate, or move them to another machine, you can copy them out:

# On macOS — copy from the Lima VM to your local filesystem
limactl copy clawstainer:/var/lib/clawstainer/snapshots/hermes-ready.tar.gz ./
limactl copy clawstainer:/var/lib/clawstainer/snapshots/openclaw-ready.tar.gz ./

# On Linux — they're just files
cp /var/lib/clawstainer/snapshots/hermes-ready.tar.gz ./

To use a snapshot on another machine, copy the tarball into the same path on that host and it'll show up in clawstainer snapshot list.

The Takeaway

Provisioning an agent sandbox is a one-time cost. The first time you set up Hermes or OpenClaw, you wait for packages to download, dependencies to compile, services to configure. After that, you snapshot it and never wait again.

The workflow is simple: create, provision, validate, snapshot. From that point on, every new sandbox is a 2-3 second boot from a known-good state. Whether you're deploying agents for a team of five or a fleet of fifty, the provisioning time is the same — near zero.

Configure once. Snapshot. Deploy instantly.