BrowserStack vs self-hosted grids

Where self-hosting wins

The browsers were never the expensive part to run

Chromium and Firefox are free software that starts in a container in under a second. When you pay $99 a month for a BrowserStack Automate Desktop parallel, almost none of that is browser scarcity; it is the fleet, the dashboard, the video retention and the operational guarantee. Those are worth money, but they are worth it in proportion to how much of your matrix is genuinely hard to run, and for a team testing current Chrome and Firefox on Linux that proportion is close to zero.

Parallelism stops being a purchase

On a cloud, halving your suite runtime means buying more parallels, so the engineering win is converted into a bigger invoice. On your own cluster the ceiling is what the scheduler can fit, and the marginal cost of the tenth concurrent browser is the compute it uses for four minutes. Aerokube Moon prices the middle ground honestly at $5 per parallel session per month with 4 sessions free, which puts 20 parallels at $100 a month against roughly $2,000 for the equivalent managed tier. That is the single biggest number on this page.

Nothing leaves the network

A cloud session means your pre-production application, its test data and a video of every interaction sit on a vendor's infrastructure. For regulated environments that is a review to pass rather than a checkbox to tick, and a self-hosted grid removes the question entirely. It also removes the tunnel: local-testing binaries exist precisely because the browser is on the wrong side of your firewall, and they are a recurring source of flakiness that disappears when the browser runs beside the app.

Where BrowserStack still wins

You cannot self-host an iPhone. A real-device lab means buying handsets, racking them, keeping them charged and network-attached, reflashing them between runs and replacing them as batteries die, and iOS automation additionally ties every device to a macOS host. Vendors do this at a scale that makes it cheap per minute and expensive per attempt, and for almost every team below a very large size, buying it is correct. Safari on real macOS carries the same problem in a smaller package: Apple hardware, licensing constraints and a Mac fleet to maintain.

The second thing that does not self-host is the past. A back catalogue of old browser and OS versions is a curation effort, not a container image, and it is exactly what you need when an enterprise customer reports a bug on a combination nobody has shipped for three years. A self-hosted grid gives you the versions you thought to keep.

Finally, be honest about the ongoing cost. Somebody maintains the images, pins the browser versions, watches the node pool and answers for it when the grid is down at release time. It is usually a few hours a month once stable and a genuine project before that. If nobody on the team wants that job, the managed cloud is not overpriced; it is correctly priced for you.

The hybrid split most teams end up with

The path that works:

1. Classify the matrix. Split your test targets into three buckets: modern Chromium and Firefox, Safari and WebKit, and real mobile devices. Count what share of runs each bucket takes; the first bucket is usually the large majority.
2. Move bucket one in-house. Run it with Playwright in your existing CI, or on Selenium Grid or Aerokube Moon if you need real concurrency and already have Kubernetes. This is the change that removes most of the bill.
3. Buy only what remains. Keep a small cloud subscription, or move to metered access such as AWS Device Farm at $0.17 per device minute, for the device and Safari slice. Paying device prices only for devices is the whole point.
4. Accept what you lose. The unified dashboard, session video across all buckets and cross-vendor flaky-test analytics all fragment. If a single pane of glass is what your organisation actually buys, say so out loud before splitting the stack, because reassembling it costs more than the licences you saved.