Browser platforms / Ferr alternative

Ferr.dev alternative

Ferr is a browser-infrastructure API with managed sessions, saved authentication profiles and replay tools. Its June pricing update meters time while browsers remain open. Compare that web tool with the Linux environment that holds the surrounding agent’s installed software and accumulated work.

Start buildingCompare capabilities ↓

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

When Ferr fits

Ferr fits teams that want managed browser fleets, CDP or SDK control, reusable browser authentication and shared debugging tools. Its advertised local browser path can also suit teams willing to operate browser infrastructure themselves.

When to consider Sandbox0

Consider Sandbox0 when the agent needs retained system tools, configuration, repositories and growing files beyond browser storage. Keep Ferr as a remote tool if useful, or test a compatible browser engine in your template; the runtime does not automatically provide the managed fleet or routing features.

Capabilities

Ferr and Sandbox0: what persists?

Feature comparison with documentation and verification status
Environment and runtime lifetimeFerrNot 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 filesFerrReusable browser profiles are documented; an independent durable Linux disk contract is not established.View evidence ↗Sandbox0The writable RootFS survives successful checkpoints, including software, system configuration, dependencies, and user data.Read documentation →
Whole RootFSFerrBrowser-profile state does not establish complete writable 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 stateFerrWarm browser sessions and replay tools are not a documented compute-free machine checkpoint.View evidence ↗Sandbox0Pause compute between tasks; resume on available capacity. Default resume starts fresh processes from the saved filesystem.Read documentation →
Memory and process stateFerrRecorded browser activity does not establish arbitrary process-memory restore.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.

Ferr’s profiles preserve browser login data, while browser-hour plans describe usage. The reviewed sources do not establish automatic growth of a customer-controlled Linux RootFS. Sandbox0 retains the broader system installation and growing agent files around the browser tool.

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.

Ferr’s profile reuse and replay inspection are distinct from reading and editing an agent’s paused Linux RootFS. Store durable outputs explicitly; the reviewed public material does not establish that full filesystem interface.

See paused file operations →

Browser profiles retain selected web state

Ferr describes profiles that save cookies, localStorage and authentication state for reuse between sessions. That can reduce repeated logins. It does not establish retention of arbitrary Linux packages, background services or a complete writable RootFS outside the browser profile.

Source 1 ↗

Warm and observable does not mean compute-free

The pricing update defines browser hours as time sessions are actually open, rather than requests or pages. Ferr’s live view, console/network logs and replay help inspect browser work; replay artifacts do not establish arbitrary process-memory restoration or a paused Linux filesystem interface.

Source 1 ↗Source 2 ↗

Cloud and local browser operation have different responsibilities

Ferr advertises the browser used in its cloud as available to run locally, while Scale lists self-hosting and volume options. Operating that browser still requires compute, networking, updates and artifact handling. A general-purpose agent runtime and a managed browser can be complementary parts of the system.

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.

Ferr

Pricing reviewed 2026-10-18

Hobby
$0; up to 50 browser-hours/month
Three concurrent sessions; replay and logs shown.
Rate source ↗
Pro
$99/month including 1,000 browser-hours
50 concurrent sessions; stealth/profiles, dedicated-IP add-ons and email support listed.
Rate source ↗
Scale
Custom browser-hour terms
Volume pricing, capacity, SLA and self-operated deployment terms need the actual agreement.
Rate source ↗

Browser time is not a CPU/RAM resource quote. The public cards do not establish the overage price after Pro’s included hours or the cost of every dedicated-IP add-on. Do not infer those rates from $99 divided by 1,000 or treat advertised unlimited Scale concurrency as unlimited free execution.

Check current Ferr 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 Ferr

  1. Inventory session/profile identifiers, IP routing, important outputs, concurrent browsers and actual open-session hours.
  2. Port compatible agent code and Linux dependencies to Sandbox0, keeping Ferr as the remote browser or supplying a tested local browser setup.
  3. Validate authentication reuse, replay/export needs, retained system tools, RootFS growth, paused files and total browser/IP plus runtime cost.

Common questions

Is Sandbox0 a drop-in Ferr 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 ↗ferr.dev/ ↗ferr.dev/blog/pricing-update/ ↗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 →