Build vs buy: what a browser fleet actually costs
Published
The build-versus-buy conversation about browser infrastructure almost always starts in the wrong place. Someone opens a spreadsheet, puts a vendor's per-hour price in one column and a cloud instance's per-hour price in the other, observes that the instance is cheaper, and concludes the question is settled.
The instance is cheaper. That is not in dispute and it is not the interesting part. Chromium in a container on a machine you rent costs a fraction of what anyone charges to run it for you, and any vendor claiming otherwise is arguing against arithmetic.
The question is what else is in the column.
What running browsers actually involves
Start with what you are committing to, because the list is longer than it looks and most of it is not obvious until you are three months in.
Process lifecycle. Browsers crash. They hang in ways that are not crashes, which is worse, because a hung process holds its slot and its memory and reports itself healthy. You need a supervisor that can distinguish "working on a slow page" from "wedged", and the honest version of that supervisor is more subtle than a timeout.
Memory growth. A long-lived Chromium in a single-page application accumulates. Detached nodes, listeners, caches. It does not leak in the classic sense so much as it grows, and the growth is a function of the pages you visit rather than of anything you control. You need per-process memory ceilings and a recycling policy, and you need them before the first incident rather than after.
Concurrency and scheduling. How many browsers fit on a machine is not a constant. It depends on the pages. A dashboard-heavy portal will support a third as many concurrent sessions as a document-heavy one on identical hardware. Static provisioning either wastes most of the machine or falls over on a bad day, and the scheduler that fixes this is a real piece of software.
Network egress. Every session needs an exit. This means addresses, and addresses accumulate reputation, and reputation is not something you control unilaterally. It also means a policy layer, because a browser with unrestricted egress is a browser that can reach your internal network.
Isolation. Sessions execute untrusted code — every page runs JavaScript, that is what pages do. Sharing a kernel between tenants or between a session and your control plane is a decision, and it should be a deliberate one. Container hardening (user namespaces, dropped capabilities, seccomp, a mandatory access control profile, default-drop networking) is a meaningful amount of work to get right and easy to get subtly wrong.
Observability. When a run fails, someone has to find out why. That means recording enough of the session to reconstruct it, storing it somewhere, expiring it on a schedule, and controlling access to it — because a replay of an authenticated session is a copy of whatever was on that screen.
Browser version management. Chromium ships every few weeks. Behaviour changes. Your automation is coupled to it whether you acknowledge that or not, so someone has to test, roll and roll back, and someone has to be able to pin a version when a release breaks a specific portal.
Upgrades under load. All of the above, again, without dropping the sessions currently running.
None of these is hard in isolation. That is exactly the trap: each one is a two-day problem, and there are eight of them, and they recur.
A cost model that includes the real numbers
Here is a structure worth filling in with your own figures rather than trusting anyone's published ones.
Compute. Browser-hours times the instance cost per browser-hour. Take your peak concurrency, not your average, unless you have built the scheduler that lets you run at average. This is the number everyone calculates and it is usually 15 to 30 per cent of the total.
Egress and addresses. Bandwidth plus whatever you spend on addresses with usable reputation. Highly variable, and it goes up rather than down over time.
Storage. Replays, screenshots, artefacts. Cheap per gigabyte and surprisingly large in aggregate, and the surprise arrives about four months in, which is also when someone asks how long you have been keeping post-authentication screenshots of a customer's finance portal.
Engineering — build. The honest figure for a production-grade fleet, meaning one with supervision, recycling, scheduling, egress policy, hardened isolation, replay capture and a version pipeline, is measured in engineer-months, not engineer-weeks. Teams that report otherwise have usually built the first three and not yet met the reasons for the other five.
Engineering — run. This is the line that decides the question and the one most often omitted entirely. It does not end. Chromium keeps releasing. Machines keep failing. The scheduler keeps needing tuning as your workload mix changes. A fleet that nobody is maintaining is a fleet that is quietly degrading.
The reliability tax. Failed runs cost twice: the compute you spent failing, and the compute you spend retrying. At agent prices, where a diverged run can burn forty turns of tokens before anyone notices, this line can exceed the compute line outright. It is also the line that improves most from operational maturity, which is precisely what you are choosing to build or buy.
Opportunity cost. What the same engineers would otherwise ship. Not a soft number — for most teams it is the largest one on the page, and the reason it feels soft is that it never appears on an invoice.
Fill those in with your figures. The ratio between the first line and the sum of the rest is the actual answer, and for most teams it is not close.
Three cases where building is right
This is not a rhetorical setup. There are real cases, and a vendor who pretends otherwise is not worth listening to on anything else.
Scale past the point where margin dominates. There is a volume above which a vendor's margin exceeds the fully-loaded cost of a team maintaining a fleet. If you are running browsers continuously at high concurrency, and the workload is stable enough that the fleet is not being redesigned every quarter, build. The crossover is a real number you can calculate from the model above, and it is higher than most people guess because the run-cost line is persistent.
Requirements no vendor meets. A specific Chromium build, a custom extension that has to be present, hardware that is not commodity, a network position inside your own perimeter, an air-gapped environment. If the requirement is genuine, the decision is made for you.
Browser infrastructure is your product. If you sell automation, the fleet is not overhead — it is the thing customers are paying for. Outsourcing your differentiator to a competitor's dependency is a strategic choice you should make deliberately if at all.
Note what is not on that list: "we have strong engineers". Everybody's engineers are strong. The question is not capability, it is whether this is where you want that capability spent for the next several years.
The middle path most teams should consider first
Before the binary, there is an option that gets skipped: buy the fleet, own the automation.
The thing that makes browser infrastructure feel like a lock-in risk is the vendor SDK. If your code is written against a proprietary client, migrating means a rewrite and the vendor knows it. But browser automation has a standard interface — the Chrome DevTools Protocol, and Playwright and Puppeteer on top of it — and a provider that exposes a plain connect endpoint is offering you infrastructure rather than a platform.
// Local. Everything below this line is your code.
const browser = await chromium.launch();
// Remote. Everything below this line is still your code.
const browser = await chromium.connectOverCDP(process.env.BROWSER_WS);
If that is genuinely the whole diff, then the buy decision is reversible: your automation is portable, the vendor is a line in an environment variable, and building later remains available at the cost of standing up a fleet rather than rewriting a product. That reversibility is worth more than a percentage point of unit price, and it is the single most useful thing to test in an evaluation. Ask for the connect string and run your existing suite against it. A vendor whose answer requires their SDK has told you something important.
We take the same view about our own integrations — Playwright, Puppeteer, Selenium and CDP are the interface, and the reason to stay should be that the fleet is well run, not that leaving is expensive.
Working the model with real numbers
Abstract cost models are easy to nod along to and hard to act on, so here is the arithmetic with figures filled in. Substitute your own; the point is the shape, not the values.
Take a team running 200 browser-hours a day — say 25 concurrent sessions for eight hours — against a mix of supplier portals. That is roughly 6,000 browser-hours a month.
Buying. At a commodity rate of a few cents per browser-hour, the invoice is in the low hundreds of euros a month. Add inference separately, because it is the same either way and does not belong in this comparison.
Building. The compute to run 25 concurrent Chromium instances comfortably is one or two mid-sized machines, which is less than the invoice above. So far the spreadsheet is winning.
Now the rest. Assume the build is six engineer-months to get from "it works on my machine" to something with supervision, recycling, a scheduler, egress policy, hardened containers, replay capture and a version pipeline. Assume the run cost settles at twenty per cent of one engineer — that is one day a week, which is optimistic for a fleet nobody has automated the operations of yet.
At any plausible fully-loaded engineering cost, that twenty per cent alone is several times the monthly invoice, permanently. The six months of build is a larger number still, and it is spent before the first production run.
The crossover is where the vendor's bill exceeds ongoing operations, and at 6,000 browser-hours a month it is not close. Multiply the volume by fifty and the arithmetic reverses, which is exactly why the answer is a function of scale rather than a matter of principle.
Two lines are missing from that comparison and both favour buying more than the numbers suggest: the six months of opportunity cost, and the reliability tax during the period when the fleet is new and the failure modes have not been met yet. Neither appears on an invoice. Both are real.
The questions that separate infrastructure from a platform
If you decide to buy, the evaluation is narrower than most vendor comparison pages suggest. Six questions, and the first one is worth more than the other five together.
Does my existing script connect with one line changed? If yes, you are buying infrastructure and can leave. If the answer involves an SDK, a DSL or a workflow builder, you are buying a platform and the switching cost is a rewrite. Both can be reasonable purchases; they are not the same purchase.
What is the session ceiling? Maximum duration, and what happens at the limit. A workflow that takes forty minutes is impossible on a thirty-minute ceiling, and this is discovered late with depressing regularity.
Does state persist between sessions? If profiles do not persist, every run starts logged out, and for authenticated work that turns a two-minute task into a twelve-minute one with a multi-factor prompt in the middle.
Where does the session actually run, and who operates it? Two questions, and the second one is the one a data protection review will ask. The region menu answers the first.
What is captured, and for how long? Replays are the difference between a five-minute diagnosis and a two-day one. They are also a recording of everything the agent saw after logging in, which is a retention question and an access-control question at the same time.
What is the failure behaviour under contention? When the provider is at capacity, do you queue, get rejected, or get a degraded session? All three are defensible. Not knowing which is not.
A decision scorecard
Score each row for your situation. It is not a formula, but the shape of the answer is usually visible by the end.
| Question | Points toward building | Points toward buying |
|---|---|---|
| Sustained concurrency | Consistently high | Bursty or low |
| Workload stability | Same shape for years | Changing quarterly |
| Team size | Can dedicate people permanently | Cannot |
| Chromium requirements | Custom build or extensions | Stock is fine |
| Network position | Must sit inside your perimeter | Public egress is acceptable |
| Compliance posture | You must operate everything | A processor is acceptable |
| Is this your product? | Yes | No |
| Time to first value | Months are acceptable | Needed this quarter |
One clarification on the compliance row, because it is where the reasoning most often goes wrong. "We must run it ourselves for GDPR reasons" is usually not correct as stated. A processor relationship is a normal, lawful arrangement with a well-defined shape: a data processing agreement under Article 28, a sub-processor list, documented technical and organisational measures, defined retention. What is genuinely difficult is not using a processor — it is using one whose parent company sits in a jurisdiction with extraterritorial disclosure powers, which is a question about the vendor rather than about buying versus building. If EU-only processing is the requirement, an EU-operated vendor satisfies it and a self-hosted fleet on a US hyperscaler does not, which is the opposite of the intuition. That distinction is worth reading properly, and it is where residency and sovereignty diverge.
The honest summary
Compute is cheap. Operations are not. The published per-hour price is comparing the one line where building always wins against a service whose value is concentrated in the seven lines underneath it.
For most teams, most of the time, the fleet is not where the differentiation lives, and the run-cost line never goes away. But the calculation is genuinely situational, and if your numbers say build, they say build.
What is not situational is the portability question. Whichever way you decide, decide it against a standard protocol, so that you can decide differently later without it being a project.