What does renting a hosted browser and device fleet stop you having to operate?

## The line renting moves A hosted browser and device provider sells you **time on machines it operates**. Your suite does not change shape: the test process still runs on your runner, still holds a client, still sends commands and reads results back. What changes is who owns and administers the machine on the far end of those commands, and with it a whole category of work leaves your team. It helps to picture a test platform as two estates that happen to be adjacent: - **The machine estate** — hosts and their operating systems, the browser and driver builds installed on them, the images those are baked into, the capacity that must exist before a run can start, and the hardware underneath all of it. - **Your estate** — the harness, the assertions, the fixtures and test data, the runner process, the pipeline that starts it, the credential that opens the account, the reporting, and the teardown. Renting transfers the first estate and leaves the second exactly where it was. Almost every misunderstanding about hosted fleets comes from expecting it to transfer more. ## What genuinely goes away - **Hosts to patch.** Operating-system updates, security patching, disks filling with profiles and crash dumps, a host quietly drifting away from its siblings — all of that becomes somebody else's rota. - **Browser and driver builds to install.** On a fleet you run, a browser and the driver that speaks to it have to be installed together and kept compatible; every browser refresh is a change you make, test and roll out. - **Images to rebuild.** A container grid encodes that pairing in an image, so the same refresh becomes a rebuild and a redeploy on your schedule. - **Hardware to buy and replace.** Machines to specify, purchase, rack, power, monitor and eventually retire — and, for anything that is not a Linux host, machines you may need a licence to run at all. - **Capacity nobody is using.** Fleet capacity you own exists whether or not a suite is running; a nightly pack that finishes before dawn leaves the rest of the day standing idle. ## What stays yours, unchanged This is the half that gets skipped, and it is the half that keeps costing engineering time: 1. **The suite itself.** Selectors, waits, assertions, data setup and the design of the cases. A rented fleet runs a badly written test exactly as badly as your own hosts did. 2. **The runner.** Something on your side still holds the client process, and if that process dies the sessions it opened do not tidy themselves up out of politeness. 3. **The pipeline.** Triggering, ordering, artefact collection and the exit-code contract are all still yours. 4. **Teardown.** Closing what you opened matters more than before, not less, because the machine on the far side is not yours to reboot. ## What renting adds The additions are structural, and each is easy to miss when the pitch is "no infrastructure": - **An outside service inside every run.** Every command your test issues now crosses a network to an organisation you do not operate, on a maintenance and change schedule you do not set. Your suite's ability to run at all acquires a dependency that no amount of local care removes. - **An account credential.** A grid inside your own network may need no authentication at all; a rented fleet is reached across the public network with a standing credential to store, inject, keep out of logs and rotate. That is genuinely new work, traded for the patching you stopped doing. - **A charge that follows use rather than a purchase.** Buying machines is a decision made once and lived with; renting turns capacity into something consumed per run, so spending tracks running. How that consumption is counted, capped and forecast is a subject of its own and worth learning separately — the shape to carry away here is simply that it now moves with your usage. | | Self-operated fleet | Rented fleet | |---|---|---| | Hosts and their patching | yours to run | the provider's | | Browser and driver builds | you install and pair them | already present on the far side | | Hardware | you buy, rack and replace it | you never see it | | Unused capacity | sits there whether used or not | you hold no machines between runs | | Harness, data, pipeline, teardown | yours | still yours | | Failure investigation | you can reach the machine | only what was sent and what was kept | ## Why the distinction matters when you are asked The weak answer is "it is fully managed, so there is nothing left to run". A hosted fleet removes an *infrastructure* job, leaves an *engineering* job untouched, and adds a third-party runtime dependency, a credential and a charge. The strong answer names all three movements — something leaves, something stays, something new arrives — and does not pretend the middle one is small. A good way to test your own grasp of it: take a concrete suite, say the regression pack for a regional railway's seat-reservation site, and walk a run end to end marking each step **mine** or **theirs**. The pipeline trigger, the checkout, the fixture load, the assertions and the report are yours. The browser process, the host it runs on and the build it happens to be are theirs. The command travelling between them is the seam, and everything this subject teaches sits on one side of that seam or the other.