Agent sandboxes / shellbox alternative

A Shellbox alternative for an agent that outgrows its starting disk

Shellbox provides SSH-managed Linux microVMs whose stopped state includes filesystem and process memory. It already preserves more than a workspace and offers keepalive, HTTP wakeup, and scheduled execution. Compare growth, data recovery, and billing boundaries with the agent application you operate.

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

When shellbox fits

Shellbox fits SSH-centric development and agent workloads that benefit from full-kernel microVMs, root access, per-box HTTPS, and its optional nested-virtualization backend. Existing SSH/SFTP tools and IDEs can be useful integration primitives.

When to consider Sandbox0

Consider Sandbox0 for a regional-object-storage-backed durable RootFS, automatic online filesystem growth, and supported file operations while compute remains paused. Test kernel/nested-virtualization requirements and the desired access surface separately.

Capabilities

shellbox and Sandbox0: what persists?

Feature comparison with documentation and verification status
Environment and runtime lifetimeshellboxKeepalive is documented for continuous background services; prepaid balance and deletion rules still apply.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 filesshellboxPaused and guest-shutdown paths retain disk; deletion and exhausted balance have different consequences.View evidence ↗Sandbox0The writable RootFS survives successful checkpoints, including software, system configuration, dependencies, and user data.Read documentation →
Whole RootFSshellboxWhole machine filesystem and system state are retained, not only a workspace mount.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 stateshellboxNormal stop snapshots and reconnect restores execution; guest shutdown instead cold-boots disk.View evidence ↗Sandbox0Pause compute between tasks; resume on available capacity. Default resume starts fresh processes from the saved filesystem.Read documentation →
Memory and process stateshellboxNormal pause and duplicate explicitly retain/copy memory state, subject to the selected lifecycle path.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.

Shellbox sizes and disks are fixed at creation, and duplication keeps that size. Sandbox0’s enabled RootFS growth expands one complete persistent filesystem online as the existing agent accumulates software and outputs.

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.

Shellbox’s documented SCP/SFTP path connects through SSH and can resume a stopped box. The reviewed guide does not establish compute-free paused file access comparable to Sandbox0’s supported persistent Files API.

See paused file operations →

Memory pause and guest shutdown have different results

Shellbox normally snapshots memory after the last SSH session disconnects and resumes it on reconnect. Its guide separately says a guest-initiated shutdown cold-boots from retained disk and does not retain memory. Keepalive and direct network access also have different idle behavior, so a disconnected client is not always proof that billing or compute stopped.

Fixed machine size includes a fixed disk

The base slot combines 2 vCPU, 4 GB RAM and 50 GB SSD, with larger fixed multipliers. Size cannot be changed after creation; copies inherit the same size. Whole-machine state is retained, but increasing total fleet capacity requires more fixed-size boxes. The vendor also explicitly leaves backups to the user.

Parked cost and prepaid deletion belong in the lifecycle

Stopped boxes retain a per-slot monthly charge. The site says machines auto-stop below a $5 balance and are deleted at $0, so parked is not equivalent to indefinite retention without funds. The top-up minimum funds usage; it is not a minimum duration of running compute.

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.

shellbox

Pricing reviewed 2026-10-18

Running base x1 slot
$0.02 per hour, billed per minute
2 vCPU, 4 GB RAM, 50 GB SSD; larger sizes multiply the slot rate.
Rate source ↗
Parked base x1 slot
$0.50 per month while stopped
Rate source ↗
Top-up minimum
$10
Prepaid funding minimum, not a minimum duration of running compute.
Rate source ↗
Subscription
No recurring subscription
Rate source ↗

Storage is tied to a fixed instance/slot rather than metered like Sandbox0’s incremental retained data. The vendor does not perform backups. Confirm host/backend compatibility, account slot limits, and balance controls; saved TCP state is not a guarantee that remote peers keep a connection alive.

Check current shellbox 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 shellbox

  1. Back up files and required system state, record normal pause versus guest-shutdown behavior, and inventory SSH, IPv6, nested-virtualization, cron, and domain dependencies.
  2. Package compatible tools and port lifecycle, commands, files, credentials, and service access to Sandbox0.
  3. Validate system changes across tasks, online disk growth, paused file access, required process behavior, recovery assumptions, and running plus parked cost.

Common questions

Is Sandbox0 a drop-in shellbox 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.

Related comparisons