Browser Automation at Scale

Running one browser is easy. Running one hundred simultaneously is a different beast entirely. Over the past year we've operated thousands of virtual browsers in production across AI agent platforms, scraping pipelines, and CI/CD systems. Here's what we learned.

Concurrency Planning

The first mistake most teams make is treating browsers like lightweight threads. A Chromium instance with a full rendering pipeline, JavaScript engine, and network stack is closer to a lightweight VM than a function call.

Each browser at Browserize runs on its own Fly machine with dedicated CPU and memory. This isolation means one tab crash never takes down your entire fleet. Plan for roughly 1 vCPU and 1-2 GB of RAM per browser for typical workloads, and scale up for JS-heavy SPAs.

Resource Allocation

Through benchmarking we've found the sweet spot for most automation tasks:

Cost Optimisation

Browser instances cost money while they're running. The most effective cost optimisation strategy is simple: stop browsers when you don't need them. Our billing tracks usage per-second, so stopping an idle browser immediately stops the meter.

For batch workloads, create browsers on-demand and stop them as soon as the job completes. For persistent AI agents, consider a pool of warm browsers that get recycled after each session. We've seen teams reduce costs by 60% just by being disciplined about teardown.

Monitoring and Observability

Every browser exposes a CDP endpoint that gives you deep visibility into its internals — network requests, console logs, performance metrics. Use this data to build dashboards and alerting for your fleet. The activity log in your dashboard also tracks every state transition for auditing.

Key Takeaways

• Isolate browsers per-machine for fault tolerance.
• Match resource limits to workload complexity.
• Stop browsers aggressively — per-second billing rewards discipline.
• Use CDP metrics for real-time observability.
• Parallelize across browsers, not within them.