Browser platforms / Steel.dev alternative

A Steel.dev alternative for the durable execution layer around your browser

Steel offers managed browsers, profiles, file APIs, credentials and optional self-operation. Profiles preserve browser identity and Global Files retain artifacts across sessions. Those are real persistence features with different scope from retaining an agent’s entire mutable Linux computer.

Start buildingCompare capabilities ↓

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

When Steel.dev fits

Choose Steel for managed browser sessions, browser profiles and credentials, shared artifacts, proxies and browser tools. It also publishes its browser implementation for teams that prefer to operate it. Keep those browser-specific capabilities in the evaluation.

When to consider Sandbox0

Consider Sandbox0 for an agent runtime whose installed software, system configuration and user data should persist together and grow online. Steel can remain the remote browser while Sandbox0 runs the longer-lived Linux agent and its tools.

Capabilities

Steel.dev and Sandbox0: what persists?

Feature comparison with documentation and verification status
Environment and runtime lifetimeSteel.devLaunch/Scale/Enterprise live-browser maxima are 15 minutes/one hour/up to 24 hours; choose timeout at creation.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 filesSteel.devGlobal Files and promoted session artifacts persist independently of a live browser; profiles preserve a separate browser directory.View evidence ↗Sandbox0The writable RootFS survives successful checkpoints, including software, system configuration, dependencies, and user data.Read documentation →
Whole RootFSSteel.devA browser userDataDir and artifact repository do not establish complete Linux RootFS retention.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 stateSteel.devReleased sessions are cleaned up; reusable profiles/files differ from a durable complete-machine compute pause.View evidence ↗Sandbox0Pause compute between tasks; resume on available capacity. Default resume starts fresh processes from the saved filesystem.Read documentation →
Memory and process stateSteel.devA profile stores browser files, not a documented arbitrary process-memory image.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.

Steel retains browser identity and global artifacts, but these sources do not establish automatic online growth of a complete persistent Linux RootFS. The 300 MB profile ceiling is a browser-profile constraint, not a claim about Global Files capacity.

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.

Steel Global Files can be managed independently of an active browser. Compare that artifact repository with Sandbox0 paused access to the persistent RootFS; neither scope should be substituted for the other.

See paused file operations →

Profiles and Global Files retain different state

Steel profiles snapshot the browser user data directory after release, with a 300 MB profile limit and automatic deletion after 30 unused days. Updating browser state requires persistProfile. Global Files are separate organization-wide storage; session files are promoted there on release, so artifact persistence should not be described as absent.

Source 1 ↗Source 2 ↗

A released session cannot be reattached as a live browser

Sessions stay live until release, failure or timeout; release cleans up compute and ends command access. The default is five minutes, and timeout cannot currently be extended on a live session. Optional inactivityTimeout releases an idle browser earlier; it does not override the hard timeout. Current plan maxima are 15 minutes, one hour and up to 24 hours.

Source 1 ↗Source 2 ↗

Current plans differ from legacy Starter and Developer offers

The current Launch plan has no monthly fee plus metered usage; Scale is $250/month plus usage. Legacy customers can retain older plans. Launch’s one-time credits expire after 90 days, and enabling managed proxies/CAPTCHA requires a $10 paid-balance deposit applied to usage, rather than an additional service fee.

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.

Steel.dev

Pricing reviewed 2026-10-18

Launch
$0/month plus usage
$30 one-time credits; current guide says valid for 90 days.
Rate source ↗
Scale
$250/month plus usage
$100 usage credits each month.
Rate source ↗
Browser hours
$0.10 Launch; $0.08 Scale
Billed by the minute, rounded up.
Rate source ↗
Proxy bandwidth
$10/GB Launch; $6/GB Scale
Rate source ↗
CAPTCHA solves
$3/1,000 Launch; $1/1,000 Scale
Rate source ↗
Browser tools
$5/1,000 calls
Rate source ↗
Scale dedicated IP
$5/IP/month
Rate source ↗
Enterprise
Custom terms
Rate source ↗

Usage credits are shared across browser time, proxies, solves and tools; advertised single-meter examples are alternatives, not additive included allowances. Browser-hour price does not include a general-purpose agent VM or model inference. Current plans and legacy-account terms should not be combined.

Check current Steel.dev 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 Steel.dev

  1. Export required browser profiles and global artifacts, and record timeout, inactivity, IP/proxy and effective current or legacy billing rules.
  2. Move compatible Linux tools and agent orchestration to Sandbox0, retaining Steel over CDP for browser-specific capabilities where useful.
  3. Validate profile writeback separately from system persistence, online RootFS growth, paused files, browser deadlines and the combined usage bill.

Common questions

Is Sandbox0 a drop-in Steel.dev 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.steel.dev/overview/profiles-api/overview ↗docs.steel.dev/overview/files-api/overview ↗docs.steel.dev/overview/sessions-api/session-lifecycle ↗docs.steel.dev/overview/pricinglimits ↗steel.dev/pricing ↗Sandbox0 RootFS capacity →

Related comparisons

Airtop vs Sandbox0 →Anchor Browser vs Sandbox0 →Bright Data Browser API vs Sandbox0 →Browser Use Cloud vs Sandbox0 →BrowserAct vs Sandbox0 →Browserbase vs Sandbox0 →