Arker’s deployment guide directs users to contact the team for early access and states that no free tier is currently offered. Verify effective account access and commercial terms. Read the source ↗

Agent sandboxes / Arker alternative

An Arker sandbox alternative for an evolving Linux environment

Arker forks full VMs from images or existing machines, including running memory when requested. It also exposes resource updates and policies outside the guest. Evaluate which state the application retains and how disk capacity changes as an agent’s environment grows.

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

When Arker fits

Arker fits teams that want warm VM forks, several host architectures and regions, and policy-controlled network access or suspension during external API work. Its full-VM environment and configurable durability are central product choices.

When to consider Sandbox0

Consider Sandbox0 when a user should return to one durable writable Linux RootFS that grows automatically as it fills, while compute can pause and supported file operations continue independently. Validate any VM-specific or architecture-specific dependency against gVisor before migrating.

Capabilities

Arker and Sandbox0: what persists?

Feature comparison with documentation and verification status
Environment and runtime lifetimeArkerVM policies can suspend execution during external API waits. That control does not establish a universal active-lifetime allowance; confirm platform and account terms.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 filesArkerPersistent disk is a configurable fork capability; verify disk and durable settings for the source and platform.View evidence ↗Sandbox0The writable RootFS survives successful checkpoints, including software, system configuration, dependencies, and user data.Read documentation →
Whole RootFSArkerWarm and disk-only source-VM forks inherit the source filesystem, with different process semantics.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 stateArkerPolicies can suspend execution and resume it when the matched external response arrives.View evidence ↗Sandbox0Pause compute between tasks; resume on available capacity. Default resume starts fresh processes from the saved filesystem.Read documentation →
Memory and process stateArkerA warm source-VM fork includes running processes; image forks and disk-only forks 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.

Arker accepts explicit disk resource updates within the machine’s supported range. The reviewed resource and policy APIs do not establish automatic online RootFS expansion based on guest free space.

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 →

Warm state and durable recovery are separate options

An Arker fork from a source VM defaults to inheriting disk and memory; a disk-only layer selection cold-boots instead. The disk and durable flags control persistent storage and recovery behavior separately. Record those choices rather than assuming every image-based or warm fork has identical failure semantics.

Resource updates still need an application policy

Arker’s update API accepts CPU, memory, and disk changes within the source platform’s supported range. Its policy API can suspend a machine while waiting for an outbound response. These are useful agent controls, but the reviewed APIs do not establish a built-in free-space-triggered RootFS growth policy.

A peer benchmark is not an Arker rate card

The public pricing document lists dated cost comparisons for other clouds and asks prospective users to contact the team. It does not establish a current numeric Arker resource tariff. Obtain current resource, suspended-state, durability and region terms before calculating an Arker bill; the peer prices are not Arker’s own rates.

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.

Arker

Pricing reviewed 2026-10-18

Current Arker resource and suspension rates
Request current account-specific terms
No numeric Arker resource rate was verifiable in the reviewed public documentation.
Rate source ↗
Free tier
Not currently offered in the deployment guide
Rate source ↗

The public pricing document’s dated competitor benchmark is excluded from the Arker price rows. Confirm currency, platform, region, active time, suspension, retained state, and durability charges with the vendor. No savings percentage can be established from the reviewed public material.

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

  1. Record source VM, fork layers, persistent-disk and durability options, architecture, region, and resource ranges.
  2. Export files and recreate the image, policies, credentials, services, and lifecycle decisions; port VM-specific tools after compatibility testing.
  3. Validate repeated tasks, installed packages, automatic RootFS growth, paused Files API access, and the process-state continuity the workload requires.

Common questions

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