CI and test infrastructure / Blacksmith (GitHub Actions runners) alternative

Blacksmith.sh alternative for persistent agent workers

Blacksmith runs GitHub Actions jobs and offers Sticky Disks for selected persistent paths. Its early-beta Testboxes let coding agents sync local changes into a warm CI microVM and run commands. Compare these CI-oriented lifecycles with an agent’s durable returning Linux computer.

Start buildingCompare capabilities ↓

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

When Blacksmith (GitHub Actions runners) fits

Choose Blacksmith for GitHub Actions compatibility, its cache integrations and running agent-requested CI checks against local changes. Keep the GitHub workflow, token and service-container behavior when those are essential.

When to consider Sandbox0

Consider Sandbox0 when the agent needs retained system tools and a complete growing RootFS between tasks. GitHub Actions orchestration, CI result handling and local-worktree synchronization remain integrations you retain or implement.

Capabilities

Blacksmith (GitHub Actions runners) and Sandbox0: what persists?

Feature comparison with documentation and verification status
Environment and runtime lifetimeBlacksmith (GitHub Actions runners)Beta Testboxes default to a thirty-minute idle timeout. Warm command execution does not establish durable machine recovery after cleanup; Sticky Disk retention is separate.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 filesBlacksmith (GitHub Actions runners)Selected Sticky Disk paths persist through committed snapshots, with seven-day inactivity eviction.View evidence ↗Sandbox0The writable RootFS survives successful checkpoints, including software, system configuration, dependencies, and user data.Read documentation →
Whole RootFSBlacksmith (GitHub Actions runners)Sticky Disks do not establish persistence of the complete writable runner RootFS.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 stateBlacksmith (GitHub Actions runners)A warm Testbox remains an executing CI job; durable machine pause/resume is not established.View evidence ↗Sandbox0Pause compute between tasks; resume on available capacity. Default resume starts fresh processes from the saved filesystem.Read documentation →
Memory and process stateBlacksmith (GitHub Actions runners)Warm commands do not establish arbitrary RAM checkpoint recovery after cleanup.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.

Sticky Disks provide real selected-path persistence but retain a seven-day idle eviction policy. Larger runner disks and cache clones do not establish an automatically growing durable complete agent RootFS across jobs.

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.

Sticky Disk management and retained workflow records are separate from direct read/write access throughout a paused guest RootFS. Testbox commands require its live CI environment.

See paused file operations →

Sticky Disks retain mounted paths through committed clones

Each job mounts an isolated clone of the last committed Sticky Disk snapshot. Job completion can commit a new snapshot for future jobs, with optional branch protection governing who may commit. This is selected-path persistence, rather than automatic retention of the runner’s complete root filesystem.

Source 1 ↗

The cache has an inactivity deletion policy

A Sticky Disk is purged after seven consecutive days without a mounting job. Its lifecycle is therefore unsuitable as the sole copy of irreplaceable long-idle agent state. Storage has its own per-GB monthly charge, separate from runner time.

Source 1 ↗

Testboxes keep a CI job warm, not indefinitely archived

The early-beta Testbox runs commands inside a real GitHub Actions job, with secrets, OIDC and service containers. It uses rsync to mirror local changes and stays warm for multiple commands. Default idle timeout is 30 minutes; the guide does not establish durable machine recovery after cleanup.

Source 1 ↗

Read resource-weighted allowances and benchmark claims carefully

The documented free pool is 3,000 x64 two-vCPU-equivalent minutes per organization/month; larger and other-platform runners consume it at different rates. The pricing page’s savings headline assumes an estimated speedup. It is not a throughput guarantee for your workload.

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.

Blacksmith (GitHub Actions runners)

Pricing reviewed 2026-10-19

Published Ubuntu x64 starting configuration
$0.004 per minute
The selected runner size changes the rate; compare the effective shape.
Rate source ↗
Sticky Disks
$0.50 per GB/month
Separate storage meter; seven-day inactivity eviction applies.
Rate source ↗
Static IP add-on
$100 per IP/month
Optional and separate from runner/storage use.
Rate source ↗
Testbox execution
Same per-minute runner pricing as CI
Early beta; default idle timeout 30 minutes; account/resource terms apply.
Rate source ↗

Free minutes are resource-weighted equivalents, not 3,000 actual minutes on every runner. The reviewed price page uses a speedup assumption in its savings headline; no universal savings or throughput result is adopted here. A coming-soon sandbox label does not establish a separate generally available sandbox contract.

Check current Blacksmith (GitHub Actions runners) 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 Blacksmith (GitHub Actions runners)

  1. Inventory runner types, Sticky Disk keys/paths, branch protection, inactivity retention and Testbox synchronization/timeout.
  2. Export important cached data before eviction and integrate compatible persistent agent work with Sandbox0 while keeping required CI orchestration.
  3. Test system-tool retention, RootFS growth, paused files, local sync semantics and full weighted runner, storage, IP and model costs.

Common questions

Is Sandbox0 a drop-in Blacksmith (GitHub Actions runners) replacement?

Evaluate API compatibility and product scope. These products serve different core workflows, so a change may require a different architecture.

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.blacksmith.sh/blacksmith-caching/dependencies-sticky-disks ↗docs.blacksmith.sh/blacksmith-testbox/overview ↗docs.blacksmith.sh/blacksmith-runners/overview ↗www.blacksmith.sh/pricing ↗Sandbox0 RootFS capacity →

Related comparisons

Apple Xcode Cloud vs Sandbox0 →Artillery vs Sandbox0 →AWS CodeBuild vs Sandbox0 →Azure Pipelines vs Sandbox0 →Bitbucket Pipelines vs Sandbox0 →Buildkite hosted agents vs Sandbox0 →