The True Cost of an In-House Selenium/Playwright Grid

Open source is free. The grid is not.

Selenium and Playwright cost nothing to download. That much is true. But the moment you need a grid that runs those tests in parallel, persists across CI pipelines, scales under load, and stays alive as your application evolves, you have crossed from "free framework" into "infrastructure project." The download was free. The next two to three engineer-years of work were not.

This article models what that gap actually costs. Not as a vendor pitch. As a line-item budget exercise any engineering manager can replicate with their own numbers. If you already run a self-hosted grid and you are happy with it, this model is a useful audit. If you are evaluating whether to build one, these are the numbers you should stress-test before you commit.

For the setup and configuration side of running a self-hosted grid, the adjacent companion post self-hosted E2E testing platform covers the how-to. This post is only the cost angle.

The four cost lines of a self-hosted grid

Every self-hosted Selenium or Playwright grid has the same four cost lines. The proportions shift depending on team size and suite complexity, but none of the lines disappear.

Cost line	What drives it	Modeled annual range (5-eng team, 200 tests)
Cloud VM infra	Browser node count, uptime model (always-on vs autoscaled), cross-browser matrix	$12,000 - $50,000
Setup engineer-time (amortized)	Hub/node config, Docker images, CI wiring, autoscaling logic, initial test authoring	$14,000 - $25,000
Ongoing maintenance	Selector drift, flow changes, browser/driver upgrades, flaky test rewrites	$28,000 - $40,000
Flake-chasing	Triage time per non-deterministic failure; grows with suite size and release cadence	$16,000 - $31,000

The infrastructure line is the most visible. Browser nodes cost real money whether they sit on always-on VMs or spin up via autoscaling. A modest parallel grid running Chrome, Firefox, and a headless configuration across several concurrent sessions will consume at least a few hundred dollars per month in cloud compute before you add storage, egress, or a managed orchestration layer. That scales toward tens of thousands of dollars annually at meaningful parallelism.

The setup line is real but finite. Building a grid from scratch, which includes Docker images for each browser, a Selenium Hub or Playwright server, autoscaling configuration, and the wiring to make CI trigger and report on it, takes between three and four engineer-months for a 200-test suite, according to ContextQA's published build-effort figures. At a fully loaded engineer cost of roughly $120,000 per year (about $60 per hour, per ITConvergence's published cost data), that is $45,000 to $60,000 in labor. Amortized over a three-year grid life, the annual setup cost is $15,000 to $20,000. Call it $14,000 to $25,000 once you account for re-builds after major framework upgrades.

The maintenance and flake lines are where the budget quietly compounds. More on that below.

What a self-hosted grid actually costs: a modeled TCO

Here is the worked model. This is the part of the total cost of ownership of test automation that the $0 license obscures. All figures are labeled as a model, not a vendor quote. Scale: 5-engineer team, 200 E2E tests, CI running on every PR, mid-2026 pricing.

Infrastructure. A representative always-on grid for this suite size runs four to eight browser-node VMs (e.g., e2-standard-4-class machines on a major cloud at roughly $0.13/hour each), plus a hub instance. Eight nodes at 730 hours per month yields about $760/month, or $9,100/year. Add storage, egress, and occasional scale-out bursts: call it $12,000 to $18,000/year on the low end. Teams that run a broader cross-browser matrix or higher parallelism push this toward $30,000 to $50,000. The model uses the lower bound.

Setup (amortized). Three to four engineer-months at $60/hour fully loaded is $46,800 to $62,400. Amortized over three years: $15,600 to $20,800/year. The model uses $15,600/year.

Ongoing maintenance. Industry benchmarks from ITConvergence and ContextQA consistently place annual test maintenance at 30 to 50 percent of the automation budget. The "automation budget" here is the sum of infrastructure and setup labor: roughly $60,000 to $80,000/year. Thirty percent of $60,000 is $18,000. Fifty percent of $80,000 is $40,000. At a mid-point, the maintenance line is $28,000 to $40,000/year in labor (engineer-hours re-scripting broken tests, updating selectors, chasing driver compatibility). This article models that percentage in granular dollar terms.

Flake-chasing. A 200-test suite at typical flake rates (2 to 5 percent) produces four to ten flaky failures per run. At two runs per day and 20 minutes of triage per incident, that is one to two hours of engineer time daily. At $60/hour: $300 to $600/week, or $15,600 to $31,200/year.

Modeled annual TCO (mid-2026, 5-engineer team, 200 E2E tests):

• Infra: $12,000 to $18,000
• Setup (amortized): $14,000 to $25,000
• Maintenance: $28,000 to $40,000
• Flake-chasing: $16,000 to $31,000

Total: ~$70,000 to $114,000 per year for a baseline grid, scaling to ~$147,000 per year for teams running a broader cross-browser matrix or higher parallelism. The headline range for this model is $70,000 to $147,000.

This is a model, not a quote. Every line can be stress-tested with your actual team cost, VM size, and suite flake rate. The structure of the model is what matters: four lines, not one.

Maintenance: the line item that grows

The maintenance figure deserves its own section because it is the one that surprises teams most. Infrastructure costs are visible on a cloud bill. Setup costs are felt during the build sprint. Maintenance is invisible until it is not, because it hides in weekly sprints as "fixing the tests before the release."

The 30 to 50 percent maintenance figure (ITConvergence, ContextQA) is an annual ratio against the total automation budget. What makes it compound is that it is not a fixed cost. Every new feature adds tests. Every refactored component breaks selectors. Every browser update breaks at least one timing assumption. A 200-test suite that takes 30 percent to maintain today will take 35 to 40 percent in 18 months, because the suite is bigger and the application is more complex.

The underlying mechanism is simple: scripted tests are fragile by construction. A scripted test encodes specific selectors, specific flows, and specific timing expectations. When any of those change, the test breaks. The test does not know the difference between a broken feature and a renamed button. Someone has to look. That someone is an engineer. At $60/hour, that engineer costs $480/day.

Teams often do not notice the total cost of this because the maintenance is distributed. No single ticket says "fix flaky tests: $2,000." It shows up as two hours here, three hours there, a sprint backlog item deferred from the last three planning sessions. Aggregate it over a quarter and the number becomes visible. Aggregate it over a year and it is your largest testing line item.

This is where a codebase-first approach changes the math. When Autonoma reads your code rather than your recorded clicks, it generates tests that are structurally aware of your application. The Diffs Agent runs on every PR, analyzes the code changes, and updates, adds, or deprecates test cases to match. There is no selector to re-script. There is no flow to re-record. The maintenance line shrinks toward zero because the agents do what a scripted test authoring process cannot: track the code as it changes.

How Autonoma Removes the Maintenance Line

The core problem this article prices is not that grids are expensive to run. It is that scripted tests are expensive to keep alive. The grid is the symptom. The maintenance burden is the disease.

We built Autonoma around the premise that your codebase is the spec. A Planner Agent reads your routes, components, and user flows, then generates test cases from that analysis. An Executor Agent runs those cases against a live per-PR managed preview environment. A Reviewer Agent classifies each result: real bug, agent error, or test/plan mismatch. A Diffs Agent runs on every PR, inspects the code changes, and keeps the test suite aligned automatically.

The result is that the three cost lines this model calls out as compounding (setup labor, ongoing maintenance, flake-chasing) are structurally addressed. Setup labor disappears because there are no test scripts to write. Maintenance labor disappears because the Diffs Agent handles suite updates as the code changes. Flake-chasing decreases because the Reviewer Agent distinguishes real failures from execution noise, rather than surfacing every timing inconsistency as a red CI run.

Autonoma fits teams who would rather not run grid infrastructure or carry the maintenance line. It is honest to say that a self-hosted grid can still make sense: teams with hard data-residency requirements, air-gap environments, or deep existing grid investment have legitimate reasons to own their own infra. For everyone else, the question is whether the maintenance line in this model is worth paying permanently.

Build vs buy

The decision framing is straightforward. Build means you own the grid: you pay the infra, you pay the setup, you pay the maintenance. Buy means you pay a vendor for the grid capacity: the infra and uptime are off your plate, but scripted test maintenance is still yours.

The build-vs-buy decision framework starts with a quick anchor: Vendr's published data puts the median BrowserStack contract at $13,931 per year. That is the buy-side infra cost. The scripted test maintenance line (30 to 50 percent of your automation budget) still applies on the buy side, because BrowserStack runs your tests, it does not write or maintain them. The full buy-side cost model is in the BrowserStack pricing true cost post.

The third path is removing the scripted layer entirely. When tests are generated and maintained by agents from the codebase, both the build and buy infra lines change character: there is no grid to run, and no test scripts to maintain.

For teams without hard grid-ownership constraints, Autonoma is the cleaner economic answer: it turns the choice from "self-host or rent a grid" into "stop carrying the grid and script-maintenance lines at all."

FAQ