Session Runtime

A fresh browser, isolated to the millisecond.

One POST request spins up a dedicated Chromium instance inside a Firecracker microVM. Your agent connects over the Chrome DevTools Protocol it already speaks.

Read the quickstart See pricing

How it works

One API call. One dedicated browser.

Each POST /v1/sessions returns a WebSocket URL that speaks Chrome DevTools Protocol. Behind it we boot a Chromium process in a Firecracker microVM — hardware-isolated, single-tenant, and gone the second your agent disconnects.

No state survives a session. No other customer's cookies live in the profile. Nothing gets "reused" quietly to save money.

POST https://api.browseranvil.com/v1/sessions

{
  "region": "us-west",
  "ip_pool": "residential",
  "record": true,
  "credentials": ["acme-okta"]
}

// → { "ws": "wss://run.browseranvil.com/s/sess_2f7..." }

Built for teams that got burned once.

Every default in the runtime is the one you wish you had picked after your first outage.

Hardware isolation

Firecracker microVMs with KVM boundaries. Not a container, not a Chromium profile — a dedicated kernel per session.

Sub-second cold start

p95 under 900ms worldwide through pre-warmed VM pools. Your agent doesn't wait on us.

Deterministic fingerprints

Stable user-agent, canvas, and WebGL fingerprints pinned per session ID — so rerunning a replay hits the same bot-detection path.

Bring your own network

Datacenter, residential, or mobile IP pools. Pin a region. Rotate on demand.

CDP-native

Anything that speaks Chrome DevTools Protocol plugs in: Playwright, Puppeteer, Browser Use, Computer Use, your own stack.

Graceful shutdown

Sessions close cleanly with final DOM, network tail, and console flushed to storage.

Under the hood

The anatomy of a session.

Pool pre-warm

Idle Firecracker VMs sit warm, Chromium booted, waiting for the next request.

Claim & lock

Your request claims one VM. A network namespace binds a clean IP from your chosen pool.

Inject context

Vaulted credentials, cookies, and extensions are mounted into the session.

Reap & wipe

On disconnect the VM is torn down, disk overwritten, network bindings released.

Comparison

Why not just spin up Chromium yourself?

You can. Hundreds of teams have. Every one of them eventually rebuilds the same six systems — pooling, eviction, IP rotation, credential injection, replay, audit logging — and regrets starting.

BrowserAnvil is the version of that infrastructure you would have built, if you had six more quarters and a security engineer to spare.

Zero shared Chromium state between customers
Auto-eviction and cleanup per session
Per-region IP pools with health checking
Built-in retry, timeout, and reconnect semantics
Metered per-second, billed per-minute
Ships with every session recorded by default

Global footprint

Twelve regions. Your data, where you need it.

North America

us-west (Oregon), us-east (Virginia), ca-central (Montréal)

Europe

eu-west (Dublin), eu-central (Frankfurt), eu-north (Stockholm), uk-south (London)

Asia-Pacific

ap-south (Mumbai), ap-southeast (Singapore), ap-northeast (Tokyo), ap-oceania (Sydney)

Government

us-gov-west (GovCloud, IL2)

99.95%

Availability SLA

900ms

p95 cold start

5K+

Concurrent sessions / customer

Regions in production

Firecracker behind a CDP URL — that was all we needed. The first day saved us a month of Dockerfile work.

— Alex Ruiz, Infrastructure Lead, Operator Co

Runtime FAQ

How long can a session run?

Up to 6 hours on Team, unbounded on Enterprise. Most agent workloads complete in under 10 minutes, and we auto-extend based on activity.

Can I attach browser extensions?

Yes. Upload .crx files to your account and reference them at session creation. Common extensions (uBlock, 1Password) are pre-packaged.

Can I use a custom Chromium build?

On Enterprise, yes. Submit your build through our validation pipeline and we will host it as a region-scoped image.

Do you support mobile emulation?

Yes, any device profile Chrome supports, plus true mobile IP pools in the US, UK, and Japan.