In a CI/CD system, what is the difference between a provider-hosted runner and a self-hosted runner, and what does choosing self-hosted actually change?

## The runner is where everything actually happens A CI/CD platform has two halves. The coordinator (the server, the control plane) decides which jobs should run, in what order, and records the results. The other half is a fleet of machines that actually run the work. The process on that machine — called a runner, an agent, or an executor depending on the vendor — receives a job, checks out the code, runs the steps, streams logs back, and reports success or failure. This matters because everything a pipeline "has" is a property of that machine, not of the pipeline file. How much disk is free, which compilers are installed, whether the internal package repository is reachable, what credentials happen to be sitting in the runner user's home directory — none of that is written in the YAML. When a build behaves differently than expected, the runner is usually the reason. ## The hosted deal Provider-hosted runners are machines the CI vendor operates. They boot from a standard image the vendor maintains, run exactly one job, and are discarded. You are billed for the minutes consumed. What you get: clean state on every run with no effort, an image kept patched and stocked with common toolchains by someone else, and elastic capacity — twenty pull requests at once means twenty machines, with no capacity planning on your side. What you give up: hardware choice is limited to the sizes on the price list; there is no route from that machine into your private network, so a job that must reach an internal database or artifact repository needs a tunnel or a publicly reachable endpoint; nothing persists between jobs, so any cache must be explicitly saved and restored through the platform's cache service; and the per-minute price scales with your build volume, which is fine at ten builds a day and material at ten thousand. ## Why teams self-host Four reasons come up repeatedly, and cost is only one of them. - **Cost at volume.** Long builds on large machines eventually cost more per minute than an always-on instance you rent directly. - **Hardware the vendor does not sell.** GPUs, very large memory, a specific CPU architecture, physical test devices, or a licensed operating system. - **Network reachability.** The build needs the internal package mirror, a licence server, or a database that will never be exposed publicly. - **Compliance.** Source code or data must stay inside a particular network or jurisdiction. A large warm cache is a fifth, weaker reason — weaker because the same effect is obtainable with a shared cache service without giving up clean machines. ## What you inherit Choosing self-hosted moves three obligations onto your team. **Operations.** Someone patches the OS and keeps the toolchain from drifting away from what developers use locally. Someone notices when the disk fills with old workspaces and container images. Someone owns capacity: a hosted pool absorbs a burst, a fixed self-hosted pool grows a queue. **Isolation.** If one machine runs many jobs, those jobs share a filesystem, a user account, a process table, and whatever the previous job left behind. Without a deliberate boundary, one team's build can read another team's credentials. **The trust boundary.** This is the one candidates skip. A self-hosted runner is, functionally, a general-purpose code-execution service sitting on your internal network, and it will execute whatever the pipeline tells it to. "It is behind our firewall" is the reason it is more dangerous, not less: a hosted runner that gets compromised can reach nothing of yours, while yours can reach everything the machine can. That is why untrusted contributions — pull requests from forks of a public repository — must not be routed to self-hosted machines. ## Deciding Three questions settle most cases. What does a build-minute actually cost us at current and projected volume? Does any job need something hosted cannot provide — hardware, private-network reachability, a data-residency guarantee? And can we run the fleet properly: single job per machine, destroyed afterwards, patched, and separated from untrusted work? The common answer is a hybrid. Hosted runners take the bulk of ordinary builds and every job triggered by an outside contributor, and a small self-hosted pool handles the jobs that genuinely need to be inside the network — typically deployments and specialised builds. That keeps the expensive, high-trust footprint small enough to actually operate well.