A hard isolation boundary
Every workload runs inside a KVM-backed Firecracker microVM with its own kernel and filesystem.
Linux sandboxes for agents
Fast sandboxes.Normal compute prices.
Run production coding workloads on hardware-isolated Linux machines for a fraction of what the usual sandbox providers charge.
4.0¢per active hour2 vCPU · 4 GiB
Normalized hourly compute2 vCPU / 4 GiB
Run Cloud1×$0.040
Fly.io2.5×$0.098
CodeSandbox3.8×$0.150
E2B / Daytona / Blaxel4.2×$0.166
Cloudflare4.5×$0.180
Modal6×$0.237
Vercel8.6×$0.341
Published usage rates or nearest matching tier, reviewed July 12, 2026. Plan fees, credits, storage, network, and creation charges are excluded.
4.0¢ / hour
2 vCPU and 4 GiB at launch rates
Would rank #1*
Unofficial Dax benchmark result
Per-second billing
Pause with no compute charge
Real workload performance
Cheap because the infrastructure is efficient.Not because the machines are slow.
ComputeSDK's Dax benchmark exercises a complete coding workload inside a fresh sandbox, not just an API response or a warm-start timer.
Read the public methodologyDax / OpenCode workloadFull run
01Prepare Linux
02Install Node + Bun
03Clone OpenCode
04Install packages
05Typecheck
Run Cloud resultHighest score in our run of the public benchmark.
#1
unofficial*
*Run Cloud's result was produced by us using the benchmark's public script and is not yet included in ComputeSDK's official provider results.
Your workload, your bill
Spend your budget on the agent.Not the sandbox markup.
Set your concurrency and monthly runtime to compare the same normalized Linux workload across providers.
Broad and exact placement apply only published region-selection premiums. Providers without a published multiplier remain unchanged.
Normalized to 2 vCPU / 4 GiB. Estimates apply each provider's published usage rates or nearest matching tier to the same runtime.
Run Cloud1×
Per-second CPU + memoryFly.io≈3.3×
Performance-2x / 4 GB regional rateCodeSandbox≈5.1×
On-demand VM credit rateE2B≈5.6×
Per-second CPU + memoryDaytona≈5.6×
Per-second CPU + memoryBlaxel≈5.6×
Active compute by allocated memoryCloudflare≈6.1×
Containers at 100% active CPUModal≈8.0×
Sandbox rate at 3× base CPU + memoryVercel≈11.5×
Sandbox at 100% active CPUIllustrative usage estimate only. Plan fees, included credits, storage, network, and creation charges are excluded. Active-CPU providers assume 100% utilization; lower utilization can reduce their actual bill.
Lower switching cost
Change your provider.Not your product.
Keep the lifecycle your application already understands and move workloads over incrementally with provider-shaped compatibility adapters.
Migrating from another sandbox platform?
Keep core lifecycle and command code familiar while you move workloads incrementally. Unsupported provider-specific features fail explicitly.
Example adapter · ModalPython
compat_modal.py
# from modal import Sandboxfrom runcloud.compat.modal import Sandbox # Core create, exec, lookup, and terminate calls keep their familiar shape.Compatibility matrix
One runtime. Eight migration paths.
Start with a provider-shaped import, keep the core lifecycle familiar, then validate the provider-specific features called out by each adapter.
Swipe to compare →
| Provider | Language | Original package | Run Cloud adapter | API shape | Migration | Guide |
|---|---|---|---|---|---|---|
| 01Modal | Python | modal | runcloud.compat.modal | Sandbox | Core import change | Compare → |
| 02E2B | Python | e2b | runcloud.compat.e2b | Sandbox | Core import change | Compare → |
| 03Blaxel | Python | blaxel.core | runcloud.compat.blaxel | SandboxInstance | Core import change | Compare → |
| 04CodeSandbox | TypeScript | @codesandbox/sdk | @run-cloud/sdk/compat/codesandbox | CodeSandbox | Core import change | Compare → |
| 05Vercel | TypeScript | @vercel/sandbox | @run-cloud/sdk/compat/vercel | Sandbox | Core import change | Compare → |
| 06Cloudflare | TypeScript | @cloudflare/sandbox | @run-cloud/sdk/compat/cloudflare | getSandbox | Core import change | Compare → |
| 07Fly.io | TypeScript | Fly Machines REST API | @run-cloud/sdk/compat/fly | Machines | Core import change | Compare → |
| 08Daytona | Python | daytona | runcloud.compat.daytona | Daytona | Core import change | Compare → |
Unsupported provider-specific methods throw with a migration hint.@run-cloud/sdk · pip install runcloud-sdk
No missing pieces
Everything you expected from an expensive sandbox.
Real Linux, with root
Use apt, curl, Git, language runtimes, package managers, and the tools your coding workloads already expect.
State that can branch
Snapshot an environment, restore it later, or fork it into parallel agent work without starting over.
Pause at no compute cost
Preserve useful state between agent turns without paying for an idle machine.
Ready in under a second
Keep interactive agent work moving with cache-local images designed for sub-second startup.
One machine or hundreds
Fan out evaluations, builds, and agent branches without maintaining a standing fleet.
More than Linux when you need it
Let the same agent continue onto an iPhone.
Add browser-controlled iOS simulators and cloud Xcode builds when the work needs to leave the Linux sandbox.
FAQ
The practical details.
What teams usually ask before moving a sandbox workload across.
How much does a Run Cloud sandbox cost?
A 2 vCPU and 4 GiB Linux sandbox costs approximately $0.0296892 per active hour at current launch rates. Two vCPUs are one physical core, and CPU and memory are metered independently by the second. Sandboxes auto-scale CPU: the size is a billing floor, and usage above it bills at the same rate as its own CPU (burst) invoice line.
What does the Dax benchmark measure?
It runs a cold clone, install, and typecheck cycle for the OpenCode repository inside a fresh sandbox. The workload prepares Linux, installs Node and Bun, clones a pinned commit, installs packages, and runs the project typecheck.
Is the Run Cloud benchmark result official?
Not yet. The Run Cloud result was produced using the benchmark’s public script but is not currently part of ComputeSDK’s published provider runs. It is presented as an unofficial result until an independent run is published.
Can I migrate an existing sandbox integration?
Run Cloud provides provider-shaped compatibility adapters for common sandbox APIs. They are intended to preserve core lifecycle code while you migrate incrementally and validate provider-specific behavior.
Are these containers or virtual machines?
Run Cloud Linux sandboxes are KVM-backed Firecracker microVMs with a dedicated kernel and filesystem rather than shared-kernel containers.
See what your sandbox workload should cost.
Compare the bill, test the workload, and migrate without rebuilding your product around another provider.