The Infrastructure Behind Spinning Up Hundreds of Chrome Sessions on Demand

Spinning up one browser session is easy. Any headless library such as Playwright can do it.

The problem starts when your agent needs fifty or five hundred. Suddenly, you're provisioning machines, managing session cleanup, handling cold starts, routing traffic across geos, and debugging failures with no visibility into what each browser was actually doing.

Most browser infrastructure was designed for human-paced testing. One person, one session, one machine. AI agents don't operate that way. They fan out. They parallelize. They need infrastructure that can keep up without requiring an ops team to run it.

This is the infrastructure problem Browser Cloud is built to solve.

What Happens When You Call sessions.create()

From the outside, it looks like a single line.

const session = await sessions.create();

Under the hood, Browser Cloud allocates a real Chrome instance, establishes a CDP connection, starts the recording pipeline for video, console, and network logs, and hands you a live browser ready to receive commands - all before your agent's first instruction runs.

No provisioning step. No warmup delay. No cleanup logic to write. The session manages its own lifecycle. When you call session.release(), the instance is torn down, recordings are finalized, and the resources are freed. You never touch the machine.

This is what makes parallelism tractable. When each session is fully self-contained - isolated state, isolated recording, isolated lifecycle - you can run hundreds of them simultaneously without sessions interfering with each other or sharing a log stream you have to manually split after the fact.

We run approximately 85 million tests per month on this infrastructure. The cold start problem is solved not by clever engineering at session creation time, but by infrastructure that has been battle tested by Fortune 500 companies to startups at scale for over a decade.

Run your first session on Browser Cloud!

Concurrency Without the Overhead

Browser Cloud uses concurrency-based pricing. You pay for the number of simultaneous sessions you're running, not per token or credit based. For agent workloads that fan out aggressively and then collapse back down, this means the cost model actually matches the usage pattern.

There are no usage caps on what your agents can do within a session. Sessions can run continuously. Daily usage is 6 hours per concurrency slot under fair usage. Idle sessions time out after 10 minutes, so you're not paying for browsers that are idle and consuming resources.

For teams scaling from a handful of sessions to hundreds, this means you can grow the concurrency without renegotiating a contract every time your pipeline gets bigger.

Geography is a First-Class Concern

A lot of the web behaves differently depending on where the request comes from. Pricing pages show different currencies. Inventory shows different availability. Some pages don't load at all outside specific regions.

Browser Cloud includes geolocation support with 5 GB of free traffic built in, alongside a proxy network so your agent sessions can originate from the geographies that matter for your workload. For teams running competitive pricing pipelines or market-specific scraping, this removes an entire category of infrastructure they'd otherwise have to build themselves.

The sessions look like real browsers in real locations - because they are.

The Network Layer is Part of the Session

Most browser infrastructure treats networking as someone else's problem. You get a browser. What you do about tunnels and firewalls is up to you.

Browser Cloud doesn't separate these concerns. The network layer is part of the session object. The built-in tunnel gives your agent access to localhost, staging environments, and services behind corporate firewalls with no external setup required. Network logs are captured for every session automatically every request, status code, payload, and response time, synchronized to the session timeline.

The last point matters more than it sounds. When an agent fails because a CDN returned a 429 it wasn't handling correctly, or an internal API returned a 401 or 500 with an error payload, the network log surfaces it immediately. Without it, you're inferring failure causes from agent-side behavior, which is usually the wrong place to look.

Enterprise Requirements Don't Have to Slow You Down

Browser Cloud is SOC 2, GDPR, HIPAA, and ISO 27001 certified. It supports customizable multi-OS deployment for enterprise environments where a single configuration doesn't work across every team.

This isn't infrastructure that was built for startups and retrofitted for enterprise compliance. It's the same infrastructure 18,000+ enterprises have already been running tests on. The audit trail, the compliance posture, and the data boundaries were part of the design from the beginning.

For teams where security review is the longest step in adopting new infrastructure, this matters.

The Shortest Path From Agent to Scale

const session = await sessions.create();
// Real Chrome. Full rendering. Network layer included.
// Recording running from the first instruction.
await session.release();
// Session torn down. Logs finalized. Resources freed.

That's the entire lifecycle. Browser Cloud handles everything between those two lines - allocation, isolation, recording, network, compliance, so your agents can focus on what they're actually trying to do on the web.

The infrastructure has been running at scale for years. Your agents now have access to it.