Agent sandboxes / Sprites (Fly.io) alternative

A Fly.io Sprites alternative when agent data keeps expanding

Sprites already separate durable object-backed files from ephemeral compute. Their current documentation gives each Sprite a fixed 100 GB filesystem, making disk growth and warm-versus-cold process behavior useful points of comparison.

Start building Compare capabilities ↓

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

When Sprites (Fly.io) fits

Sprites fit agents that benefit from automatic sleep, usage-based CPU and memory, and a durable Linux filesystem without choosing a machine shape. The platform manages memory sizing and wake behavior.

When to consider Sandbox0

Consider Sandbox0 when the agent’s writable RootFS needs to grow beyond its starting size, or when your control plane needs explicit pause modes and persistent file operations while compute stays paused.

Capabilities

Sprites (Fly.io) and Sandbox0: what persists?

Feature comparison with documentation and verification status
Capability	Sprites (Fly.io)	Sandbox0
Environment and runtime lifetime	Sprites (Fly.io)Tasks keep the current run active and can be refreshed for longer work. Each individual hold expires after at most one hour unless renewed.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 files	Sprites (Fly.io)Files and installed packages persist through automatic sleep.View evidence ↗	Sandbox0The writable RootFS survives successful checkpoints, including software, system configuration, dependencies, and user data.Read documentation →
Whole RootFS	Sprites (Fly.io)Persistent Linux filesystem; runtime /tmp and volatile state have separate behavior.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 state	Sprites (Fly.io)Automatic warm/cold lifecycle releases compute.View evidence ↗	Sandbox0Pause compute between tasks; resume on available capacity. Default resume starts fresh processes from the saved filesystem.Read documentation →
Memory and process state	Sprites (Fly.io)Warm suspension preserves RAM, but cold wake drops it. Durable filesystem checkpoints exclude memory; the platform chooses the warm-to-cold transition.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.

Sprites currently document a fixed 100 GB filesystem with no storage autoscaling or user resize. Sandbox0’s growth-enabled RootFS is intended for environments whose accumulated packages and data exceed their initial capacity.

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.

Sprites exposes filesystem read/write APIs, while its SSHFS workflow uses a tunneled running guest. The cited file endpoint references do not establish a no-wake paused-file contract. Sandbox0 explicitly supports paused RootFS reads and filesystem-only mutations, with retained-memory mutations rejected.

See paused file operations →

Filesystem durability is a shared design goal

Sprites persist files and installed packages through an NVMe cache backed by durable object storage. Their current capacity is 100 GB and does not autoscale. Sandbox0’s enabled imports grow mounted XFS online within a logical ceiling up to 64 TiB.

Source 1 ↗Source 2 ↗

A warm wake differs from a cold wake

Sprites warm state freezes the VM in memory, while cold state drops volatile execution state and starts processes fresh. The platform chooses the transition, and open TCP connections are lost on either pause. Sandbox0 defaults to filesystem-only pause and offers explicit experimental memory checkpoints for compatible execution state.

Source 1 ↗Source 2 ↗

Actual-use meters need workload measurements

Sprites CPU and RAM prices meter actual consumption. Hot storage bills while awake, and cold storage bills while data is retained. Compare a measured active workload and its working set with Sandbox0’s configured-memory compute and incremental-storage meters.

Source 1 ↗Source 2 ↗

Keep background work active deliberately

The Sprites Tasks API holds the current run active. Each task lasts at most one hour; longer work refreshes it with a heartbeat, then releases it when finished. Services serve a different purpose: the runtime brings them back after a cold wake. An expired hold permits normal idle pause rather than guaranteeing process continuity.

Source 1 ↗

Durable checkpoints and file access have separate scope

The dedicated checkpoint guide captures the writable filesystem overlay and excludes RAM; restoration restarts the environment and closes active sessions. Sprites also exposes REST file read and write APIs, with a 16 MiB write limit. Those endpoint references do not specify whether paused access leaves compute asleep; verify the effective lifecycle separately.

Source 1 ↗Source 2 ↗Source 3 ↗

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.

Sprites (Fly.io)

Pricing reviewed 2026-10-19

CPU time: $0.0385 per CPU-hour actually used; Rate source ↗
Memory time: $0.021875 per GB-hour actually used; Rate source ↗
Hot storage: $0.000683 per GB-hour while awake; Rate source ↗
Cold storage: $0.000027 per GB-hour while retained; Rate source ↗

Use the Sprites section of the Fly.io rate card, not the Machines presets. The general pricing page says no plans or tiers, while the Sprites product FAQ still describes plan-based quotas and allowances; confirm account-specific subscription and concurrency terms before estimating the total.

Check current Sprites (Fly.io) 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 Sprites (Fly.io)

Export persistent Sprite files and identify services that restart after a cold wake; do not rely on warm memory as the only copy of progress.
Measure actual CPU, memory, hot working-set size, and retained cold data before translating the source bill.
Port service ingress and credentials, then test a growing RootFS and the intended Sandbox0 pause mode.

Common questions

Is Sandbox0 a drop-in Sprites (Fly.io) 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.fly.io/sprites/concepts/lifecycle/ ↗/docs/sandbox/template/configuration ↗/docs/sandbox/pause-resume ↗fly.io/pricing/ ↗/pricing ↗docs.fly.io/sprites/keeping-sprites-running ↗docs.fly.io/sprites/concepts/checkpoints.md ↗docs.fly.io/sprites/api/filesystem/read-file.md ↗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 →