Agent sandboxes / boxd alternative

A boxd sandbox alternative for a growing persistent agent

boxd already provides persistent microVM computers with memory-preserving sleep. For an agent that keeps accumulating tools and data, compare its disk sizing, network-based idle detection, recovery artifacts, and retained-state billing with Sandbox0’s growing RootFS.

Start buildingCompare capabilities ↓

Reviewed 2026-10-18 · Published by the Sandbox0 team

When boxd fits

boxd fits teams that want full microVM computers, warm memory state, forkable snapshots, SSH, and managed integrations. Its documented unlimited runtime and configurable sleep suit reusable developer and agent environments.

When to consider Sandbox0

Consider Sandbox0 when online RootFS expansion and compute-independent file access are central requirements. Its default pause starts fresh processes on resume, while explicit compatible experimental memory pause/resume can retain supported processes.

Capabilities

boxd and Sandbox0: what persists?

Feature comparison with documentation and verification status
Environment and runtime lifetimeboxdRuntime is listed as unlimited; disable network-idle sleep when unattended local work must continue.View evidence ↗Sandbox0ttl and hard_ttl default to 0 (disabled). Configure idle pause and deletion policies for the same persistent sandbox identity; an idle running sandbox still accrues compute charges.Read documentation →
Persistent filesboxdDisk survives standby, hibernation, and stop.View evidence ↗Sandbox0The writable RootFS survives successful checkpoints, including software, system configuration, dependencies, and user data.Read documentation →
Whole RootFSboxdMachine disk state can be retained and backed up, separately from memory.View evidence ↗Sandbox0Persistence extends beyond /workspace to paths such as /usr/local, /etc, and /home. Runtime tmpfs and virtual filesystems are excluded.Read documentation →
Release compute, keep stateboxdStandby and hibernation retain execution state; stop is a fresh-process lifecycle.View evidence ↗Sandbox0Pause compute between tasks; resume on available capacity. Default resume starts fresh processes from the saved filesystem.Read documentation →
Memory and process stateboxdNamed snapshots capture memory and disk; disk-only backups differ.View evidence ↗Sandbox0Experimental memory checkpoints can preserve compatible process state. Use memory: true on both pause and resume on a compatible deployment. A filesystem checkpoint alone does not preserve running processes.Read documentation →

Online RootFS growth

On growth-enabled images, Sandbox0 automatically expands the writable RootFS as free space runs low, within a configured sparse logical ceiling up to 64 TiB. Agent processes keep running. Growth is enabled in the qualified Cloud region; confirm activation for other regions. Existing images and snapshots retain their captured storage geometry. The ceiling is logical capacity, not preallocated host disk.

boxd’s resource guide lists a fixed default disk capacity and copy-on-write usage. Sparse billing for bytes written does not establish automatic expansion of the guest filesystem’s capacity; confirm larger-disk options for the account.

Files while compute is paused

Sandbox0's Files API reads persistent files without resuming compute. Filesystem-only pauses also permit edits; retained-memory pauses are read-only and reject mutations with 409. SSH, SFTP, file watching, and runtime-only mounts require running compute.

See paused file operations →

Standby, hibernation, and stop retain different resources

boxd standby keeps memory resident; hibernation writes memory to disk; stop discards memory and running processes while keeping the disk. CPU bills only during running, standby also bills resident memory, and hibernation retains disk charges. Choose the intended sleep state when comparing idle costs.

Source 1 ↗Source 2 ↗

A network-idle timer can interrupt a busy local job

The default auto-hibernate timer watches network traffic rather than CPU work. A long computation with no network activity can sleep mid-task unless that timer is disabled. Its resource resize workflow reboots a running machine, preserving disk but losing processes; that differs from automatic mounted-RootFS growth.

Source 1 ↗Source 2 ↗

Choose the recovery artifact before a failure

boxd distinguishes host-local memory-and-disk checkpoints, named snapshots replicated across hosts, and disk-only object-store backups. Backup scheduling is off by default. A backup restores a cold-boot disk, whereas a named snapshot can seed new machines with captured memory; those artifacts serve different recovery needs.

Source 1 ↗Source 2 ↗

Pricing

Compare billing models, then price your workload

CPU allocation, memory, billing minimums, disk, plan fees, and supported workload differ. These meters are not equal-performance machine quotes. Confirm region, resource units, and included allowances before estimating a total.

boxd

Pricing reviewed 2026-10-18

Running CPU
EUR 0.039 per vCPU-hour
Based on the full provisioned CPU count while running.
Rate source ↗
Resident RAM
EUR 0.012 per GiB-hour in use
Charged while running or in standby; hibernation releases resident memory.
Rate source ↗
Written disk
EUR 0.00008 per GiB-hour
Charged in every machine state, based on written disk rather than provisioned capacity.
Rate source ↗

The published EUR rate card excludes VAT and has no monthly plan or per-seat fee. Metering is per second with periodic settlement. The pricing page labels default disk capacity in GiB while the resource guide uses GB; confirm the actual byte capacity. A dollar comparison requires an explicit exchange-rate assumption.

Check current boxd pricing ↗

Sandbox0

$0.015/GiB-hour compute (billed by the second at approximately $0.000004167/GiB-second), plus $0.02/GiB-month of retained incremental RootFS and memory checkpoint data. Shared base images and platform recovery retention are excluded; paused sandboxes accrue storage charges only.

Compute / GiB-hour
$0.015
Retained data / GiB-month
$0.02
Paused compute
$0.00

A 4 GiB agent, 100 running hours

$6.00 compute

4 GiB × 100 hours, billed by the second. Keeping 20 GiB of billable incremental data for a full billing month adds $0.40. CPU is derived from memory by the platform; choose a tier that fits your workload.

Understand storage billing →

Before migrating from boxd

  1. Record each machine’s sleep timers, source snapshots, checkpoints, backup schedules, and disk files before deletion.
  2. Port images, services, SSH, integrations, and network policies, then validate gVisor compatibility for tools that assume a full guest kernel.
  3. Test a CPU-busy but network-idle agent, repeated installed-package state, RootFS growth, paused file access, and explicit memory-restoration requirements.

Common questions

Is Sandbox0 a drop-in boxd replacement?

Evaluate API compatibility and product scope. A shared sandbox category does not make SDKs, lifecycle semantics, or limits interchangeable.

Does keeping files also keep a running agent?

Filesystem state and volatile process state are separate. Sandbox0 requires explicit compatible memory checkpoints to preserve running processes; its default filesystem resume starts fresh processes.

Sources and review scope

The Boat team's Battleships directory is the discovery source. References below describe the product and plan discussed on this page. Check current availability, regional terms and billing units before migrating. Where the cited material does not establish a capability or price, the comparison identifies that uncertainty.

Battleships research record ↗docs.boxd.sh/guides/suspend-resume ↗boxd.sh/pricing ↗docs.boxd.sh/guides/resources ↗docs.boxd.sh/guides/disaster-recovery ↗docs.boxd.sh/guides/snapshots ↗Sandbox0 RootFS capacity →

Related comparisons

Agent 37 vs Sandbox0 →AgentComputer vs Sandbox0 →ainclave vs Sandbox0 →Alibaba Cloud Agent Sandbox / FC / AgentRun vs Sandbox0 →Alibaba Cloud AgentBay vs Sandbox0 →Amika vs Sandbox0 →