LoginGet startedDashboard
Compare · Sandboxes

Sandal vs run.cloud

run.cloud is the closest thing to us in shape: Firecracker sandboxes with forks and pause, iOS simulators, and provider-shaped compatibility imports. Sandal adds the third surface, GitHub Actions runners on Linux, Windows and macOS, plus Windows and macOS machines, and publishes one rate card for all of it.

Start buildingSee the migration
Reviewed August 2026 · 3 sources
Surfaces
2run.cloud3Sandal
GitHub Actions runners
, run.cloudLinux · Win · MacSandal
Paused sandbox
$0run.cloud$0Sandal
SDKs
Pythonrun.cloudTS · PythonSandal
The honest split

Two good answers. Here is which one is yours.

Pick run.cloud if
  • Your stack is Python and their adapter matches the provider you are leaving.
  • You want Android devices specifically and their device offer fits.
  • Their per-core-second pricing lines up with your smallest machines.
Pick Sandal if
  • You need CI runners in the same account as sandboxes and simulators.
  • You need Windows or macOS machines, not only Linux and iOS.
  • Your agents are TypeScript and you want a first-party client, CLI and MCP server.

Many teams run both. runs-on is per job and a sandbox is per task; nothing here is all or nothing.

Side by side

What each one actually ships.

Documented capability as of August 2026. Where the honest answer is a qualifier rather than yes or no, the qualifier is printed. Scroll sideways on a small screen.

run.cloud compared with Sandal, August 2026
Arearun.cloudSandalWhy it matters
Runtime
Pause and forkSnapshots, copy-on-write forks, pause and resume.Snapshots, copy-on-write forks, pause to $0 and resume under 200 ms.Both have the agent-loop primitives.
Isolation
RuntimeFirecracker microVMs with a dedicated kernel.Firecracker microVM with its own kernel; containers on the same fleet for one-shot code.A tie, and a good one.
Pricing
BillingPer-core-second and per-GiB-second rates; simulators per active minute.Per second on machine time while running; simulators per second per device; paused costs nothing.Both are fine-grained; check the unit before comparing.
Surfaces
CI runnersNo public evidence.GitHub Actions runners on Linux, Windows and macOS, one runs-on change.The team that buys sandboxes usually also pays for CI minutes.
Operating systemsLinux sandboxes, iOS simulators, Android devices.Linux, Windows and macOS machines, iOS and Android simulators.Legacy and desktop workloads need Windows and macOS.
Xcode buildsListed on their site; not verified in our review.Build API and macOS runners on Apple silicon we own.Mobile teams need the build as well as the device.
Developer experience
SDKsPython, with provider-shaped compat adapters.TypeScript and Python, CLI, REST, MCP; compat imports for E2B, Daytona and Modal.TypeScript agents need a native client.
Sources · reviewed August 2026

Capabilities change and rates change. If something here is out of date, tell us and we will fix it the same week.

Price

Same shape. Two meters.

run.cloud publishes per-core-second and per-GiB-second rates rather than a rate for this shape, so we do not print one. Sandal publishes $0.036 per hour for 4 vCPU / 8 GiB, August 2026.

run.cloud4 vCPU / 8 GiB
Per-core-second and per-GiB-second rates, see run.cloud pricing
Sandal4 vCPU / 8 GiB · paused = $0
0.036$ / hour
Price your own fleetThe full rate card
How to compare

Normalise both vendors on the same unit before you compare: one sandbox, one hour, the same size. Sandal meters per second and a paused machine costs nothing, so a bill for bursty work is the sum of the seconds it actually ran.

Open the rate card →
Migration

Same shape, native SDK.

The lifecycle maps one to one, create, exec, files, stop, so the port is a small rewrite, not a re-architecture. Keep the vendor-specific glue on your side of the boundary.

agent.py−1 +1same shape, native SDK
-from runcloud import Sandbox
+from sandal import Sandal
+sandal = Sandal(api_key=os.environ["SANDAL_API_KEY"])
-sb = Sandbox.create(template="python-3.12")
-sb.exec("pytest -q")
+sb = sandal.sandboxes.create(template="python-3.12")
+sb.exec("pytest -q")
sb.pause()
  1. 01≈ 2 min

    Install the SDK

    pip install sandal or npm install @sandal/sdk, one API key.

  2. 02≈ 20 min

    Port the lifecycle

    create, exec, files, snapshot, fork and pause map one to one.

  3. 03≈ 1 afternoon

    Run both, side by side

    Same job on each for a day; then move the CI job that runs it too.

Where run.cloud is ahead

What we would rather you read here than find later.

A comparison page where the vendor wins every row is a brochure. These are real, and we would rather you land on the right tool than land on us and leave in a month.

  • 01

    Android devices.

    run.cloud lists Android devices alongside iOS simulators. Our Android surface is emulators, not physical devices.

  • 02

    Adapters for more providers.

    Their compatibility layer covers more source SDKs than our three shims today.

Before you switch

Questions teams ask before moving off run.cloud.

Very, on sandboxes: both are Firecracker microVMs with forks and pause, and both rent iOS simulators. Sandal adds GitHub Actions runners, Windows and macOS machines, a TypeScript SDK and one rate card across all of it.

More comparisons

The rest of the field in sandboxes.

All comparisons and the full matrix →
Get started

Run the same job twice.

Point one workload at Sandal and one at run.cloud. The numbers on this page are ours; the ones that matter are yours.

Start buildingRead the docs
npm i @sandal/sdk