CI and test infrastructure / Cirrus Runners for GitHub Actions alternative

Cirrus Runners alternative for returning agent state

Cirrus Runners executes GitHub Actions jobs in single-use VMs and charges for subscribed runner capacity. Its macOS, Linux and GPU classes have different resources and concurrency weights. That is useful CI capacity, with a different lifecycle from one durable computer an agent returns to.

Start buildingCompare capabilities ↓

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

When Cirrus Runners for GitHub Actions fits

Choose Cirrus Runners for GitHub Actions integration, clean job environments and sustained build/test utilization. Keep macOS jobs that require Xcode or Apple SDKs on a suitable Mac runner.

When to consider Sandbox0

Consider Sandbox0 for compatible Linux agents that accumulate installed tools and system state across tasks, need automatic RootFS growth and supported paused files. Retain CI publication, native Mac and GPU stages where they fit.

Capabilities

Cirrus Runners for GitHub Actions and Sandbox0: what persists?

Feature comparison with documentation and verification status
Environment and runtime lifetimeCirrus Runners for GitHub ActionsNot established in this reviewSandbox0ttl 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 filesCirrus Runners for GitHub ActionsEach job uses a single-use VM; caches/artifacts are selected-data workflows, not persistent job-machine storage.View evidence ↗Sandbox0The writable RootFS survives successful checkpoints, including software, system configuration, dependencies, and user data.Read documentation →
Whole RootFSCirrus Runners for GitHub ActionsA clean VM for every job does not retain the previous job’s complete writable system.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 stateCirrus Runners for GitHub ActionsGitHub job execution does not establish a general durable agent pause/resume API.View evidence ↗Sandbox0Pause compute between tasks; resume on available capacity. Default resume starts fresh processes from the saved filesystem.Read documentation →
Memory and process stateCirrus Runners for GitHub ActionsResource classes and caches do not establish arbitrary job-process RAM checkpoints.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.

Cirrus job classes have configured disk sizes and each job gets a single-use VM. A different class or cache policy is distinct from retaining and automatically expanding one complete durable agent RootFS online.

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.

Actions caches and artifacts can expose selected saved files after a job. They are not arbitrary read/write access to the previous job VM’s entire OS filesystem while that computer remains paused.

See paused file operations →

Every job starts in a single-use VM

Cirrus explicitly executes each workflow job in a single-use virtual machine to provide a clean environment. Dependency caches and artifacts can carry selected outputs, but job-installed OS changes are not a returning machine identity. Export required work before the job ends.

Source 1 ↗

A subscription buys a concurrency budget

The published $150 monthly runner price includes unlimited action minutes. Resource classes consume different concurrency amounts: the default macOS class uses one, while Extra Large uses two. A bigger class or more parallel jobs therefore changes required subscribed capacity, even with no per-minute surcharge.

Source 1 ↗Source 2 ↗

Discounts have different eligibility

Cirrus offers a 15% discount for a twelve-month commitment or a 50% nonprofit discount under its stated noncommercial conditions. They are mutually exclusive and require support to apply. Treat them as qualified offers rather than the default unrestricted monthly rate.

Source 1 ↗

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.

Cirrus Runners for GitHub Actions

Pricing reviewed 2026-10-19

Subscribed runner concurrency
$150 per month
Unlimited action minutes; buy capacity for the concurrency/resource-class demand.
Rate source ↗
Default macOS resource reference
4 M4 Pro vCPU / 16 GB RAM
Setup lists 130 GB disk and concurrency weight 1; Extra Large consumes weight 2.
Rate source ↗
Qualified discounts
15% annual OR 50% nonprofit
Mutually exclusive; commitment/eligibility and support application apply.
Rate source ↗

Compare measured workload utilization and resource classes. Vendor performance comparisons and other vendors’ example monthly costs do not establish equal throughput or universal savings. Mac/Linux/GPU classes and their concurrency weights are distinct.

Check current Cirrus Runners for GitHub Actions 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 Cirrus Runners for GitHub Actions

  1. Inventory GitHub workflow images, resource-class concurrency weights, caches/artifacts, Mac/GPU dependencies and subscription utilization.
  2. Move compatible long-lived Linux agent stages and required data to a durable template; keep native build/test and CI publishing stages on suitable runners.
  3. Test artifact handoff, system retention, low-space growth, paused files and combined subscription, storage and Linux runtime costs.

Common questions

Is Sandbox0 a drop-in Cirrus Runners for GitHub Actions 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 ↗cirrus-runners.app/setup/ ↗cirrus-runners.app/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 →Blacksmith (GitHub Actions runners) vs Sandbox0 →