For a large Testcontainers suite, how do you choose between Docker on your own CI runners and Testcontainers Cloud?

## The real question Both options give the test JVM a Docker endpoint; the difference is who owns the machines behind it. That makes this a sourcing decision, and the useful discipline is to name the dimensions before naming a preference. ## Capacity and queueing A container-backed suite is not CPU-light: a database, a broker and an emulator per job, multiplied by the concurrency your pipeline wants. A self-hosted fleet has a fixed ceiling — when every runner is busy, jobs queue, and the metric that matters to developers is wall-clock time from push to verdict, not CPU seconds. Measure queue time separately from run time before deciding anything; a fleet that is idle at 3pm and saturated at 5pm is a scheduling problem, not necessarily a sourcing one. Managed workers turn that ceiling into a cost curve instead: capacity is elastic, and the constraint moves from "how many runners did we buy" to "what are we willing to spend on peak". ## Image locality and the cache The most underrated number in this decision is the share of a job spent pulling images. On a fleet with warm caches it is near zero; on anything that starts cold it can dominate. Whichever way you go, an internal registry mirror close to where containers run is usually the higher-leverage change than switching providers — and it is worth measuring before you conclude that runners are too slow. ## Security and the trust boundary Giving a job access to a Docker daemon is a privilege grant. On a self-hosted runner, socket access is effectively host root, so the decision extends to whose code runs there — fork pull requests in a public repository are the hard case — and to whether privileged containers are permitted at all. Managed workers move that boundary outside your hosts: no socket to mount, no privileged mode. In exchange, whatever your integration tests handle now leaves your network. If those tests use production-shaped data, that is a data-governance conversation, not an engineering preference, and it needs the answer before the pilot, not after. ## Cost model Self-hosting is mostly fixed cost plus operational time: hardware or instances, patching, disk hygiene, the on-call morning when every runner is full of leaked containers. Managed capacity is variable cost that scales with test volume — attractive while volume is modest, and worth re-checking when the suite doubles. Include the operational time honestly on the self-hosted side; teams routinely omit the hours spent maintaining runners and then wonder why the comparison felt wrong. ## Parity and developer experience An underrated benefit of a managed daemon is that laptops and CI can use the same execution substrate, which kills the "passes on my machine" class of report and lets engineers with modest hardware run the full suite. The mirror-image risk is a hard dependency: if the service is unreachable, every developer and every pipeline stops. Keep a fallback path — the local daemon still works — and make sure the suite has no code that assumes one model. ## Keeping the choice reversible The engineering work that makes this decision cheap is the same work that makes tests portable: never hardcode an address, always derive host and mapped port from the container; never bind-mount a local path, stream content through the API; do not depend on a warm cache for timeouts to pass. A suite with those properties runs unchanged on a laptop, a socket-mounted runner, a nested daemon and a remote worker — so the sourcing decision becomes configuration, and can be piloted on one pipeline and reversed without a rewrite. That reversibility is the principal-level deliverable here; the vendor comparison is secondary and will change. ## How to run the decision Pilot on the noisiest pipeline. Measure four things before and after: queue time, run time, the pull share of run time, and failure rate attributable to the environment rather than to code. Put the security review and the data question in writing. Then decide, and write down what would make you revisit — usually a volume threshold or a compliance change. A decision with a stated trigger for reconsideration is worth far more in an interview than a confident preference.