# How to Run Browser Automation at Scale in the Cloud (2026) By Steven Van · 2026-10-27 Browser Use's guide covers one cloud browser per job, worker caps, cost math for 1,500 browser-hours and limits for seven providers. Browser Use has published a guide to running browser automation at scale in the cloud. It recommends a job queue in which each job gets its own isolated remote browser, driven over CDP with Playwright or Puppeteer. The [guide]() comes from the makers of [Browser Use](), and it says the facts about the six other providers come from their own docs and pricing pages, checked October 27, 2026. ## Architecture The queue is the user's own (SQS, Redis or a Postgres table). Workers pull a job, create a browser, run it, stop it, then ack the job. The number of workers is capped at the plan's concurrency limit. Each browser serves one job, so cookies and tabs are not shared between jobs, and a crash kills one job rather than ten. The guide advises recording the browser ID with the job so a cleanup job can stop browsers whose job has already finished. Logins can be saved once in a profile, and the profile ID is passed when a browser is created. ## Limits compared The guide tabulates price per browser-hour, maximum concurrent browsers and maximum session length for seven providers. - **Browser Use:** $0.02 per browser-hour, 10 concurrent browsers at $0 (rising to 50, 250, 500 and 1,000 after $100, $1k, $5k and $25k in lifetime top-ups), 4 h maximum session. - **Browserbase:** $0.12 or $0.10 per hour over included hours, 3 to 250+ concurrent browsers by plan, 15 min on Free and 6 h or more on paid plans. - **Steel:** $0.10 on Launch and $0.08 on Scale, 10 to 1,000+ concurrent, 15 min to 24 h by plan. - **Hyperbrowser:** $0.10 on Free, Startup and Scale, 1 to 1,000+ concurrent, 12 h. - **Browserless:** plans at $35, $200 and $500 a month, 2 to 80 concurrent, 2 to 60 min by plan. - **Kernel:** about $0.06 per hour headless and $0.48 headful, billed per second, nothing in standby. It allows 5 to 150 concurrent browsers and publishes no maximum session, with idle timeout up to 72 h. - **Anchor:** $0.05 per docs (the homepage calculator uses $0.09) plus $0.01 per browser created, 5 to 500+ concurrent, 3 h default with no upper limit. Browser Use says others fit better for longer sessions (Anchor, Kernel, Steel Enterprise, Hyperbrowser, Browserbase) and for long idle waits (Kernel). It runs in the US and Frankfurt, and the EU deployment has fewer features. ## Concurrency and rate limits The guide separates two limits: browsers running at once, and how fast sessions can be created or the API called. For Browser Use, API requests are max(25, 2 × concurrency) per second per project, with the general bucket capped at 100. A 429 response carries Retry-After, which should be honored. Browserbase allows 5, 25, 50 or 150+ new sessions per minute by plan, so Startup takes about 2 minutes to start all 100. The guide also lists create limits for Anchor, Steel and Kernel. Its advice is to cap workers at the concurrency limit, pace creates under the create rate and keep the backlog in the user's own queue. ## Cost example The example workload is 1,000 jobs a day at 3 browser-minutes each, with 20 running at once for 30 days. That comes to 1,500 browser-hours and 30,000 browser starts. At list prices on the cheapest plan allowing 20 at once, monthly totals run from $30 for Browser Use to $375 to $435 for Anchor, with Hyperbrowser ($150), Browserbase ($188), Browserless ($200), Kernel headless ($240) and Steel ($270) in between. Totals leave out traffic, CAPTCHA and model costs. The $30 for Browser Use assumes proxyCountryCode: null. Its proxy is on by default at $5/GB, and without it traffic is billed at $0.20/GB. At $5/GB, a job that pulls 10 MB through the proxy costs $0.05, more than 2 hours of browser time. Browser Use also charges the session timeout up front (60 minutes by default) and refunds the unused part when the browser is stopped, so a browser that is never stopped is billed to the timeout. ## Reliability checklist - Set timeouts at three levels: per page action, per job, and the browser's own session timeout. - Retry 429s, 5xx and navigation timeouts with exponential backoff and jitter, honoring Retry-After and capping attempts. - Stop browsers in finally. Closing the CDP connection does not stop a Browser Use browser. - On failure, save a screenshot, the URL, console errors and the browser ID. Recording can be turned on with enableRecording while debugging. - Give each job an ID and check it before submitting a form or paying, so a retry does not repeat the action. ## Example code The post ends with a TypeScript example using the browser-use-sdk package and Playwright. It runs N jobs with a LIMIT of browsers at a time. Each job creates a browser with a 15-minute timeout, connects over CDP, loads a page, and stops the browser in a finally block. The guide also says self-hosting Chrome in containers can be cheaper at high, steady utilization, but then scaling, fingerprints and crashes are the user's to manage. ![Browser Use]() Browser Use Open-source browser automation platform for AI agents — let LLMs drive a real browser to research, fill forms, scrape, and complete multi-step tasks. [View Browser Use →]() Sources [Original source]() [Read How to Run Browser Automation at Scale in the Cloud (2026) on Creators Toolbox]() --- Canonical source: https://creatorstoolbox.com/blog/browser-use-how-to-run-browser-automation-at-scale-in-the-cloud-2026