CI runner hosting
Answer
Self-hosted CI runners execute your build pipelines on servers you control rather than on a provider’s shared pool. A Incognito VPS VECTOR plan at $14 per month typically outperforms a hosted runner while removing per-minute billing and queue waits entirely.
| Scenario | Minimum |
|---|---|
| Small project | 2 vCPU, 4 GB RAM |
| Typical monorepo | 6 vCPU, 16 GB RAM |
| Heavy compile (Rust, C++) | 16 vCPU, 64 GB RAM |
| Docker layer cache | 140 GB+ NVMe |
The arithmetic is usually decisive
Hosted CI minutes look cheap until you count them. A team running a few hundred builds a month on 2-core hosted runners routinely spends more than a 6-core dedicated VPS costs, and gets slower builds for the money because hosted runners are modest machines under contention.
The other saving is time rather than money. A self-hosted runner has no queue — your job starts when you push. On a busy hosted pool, waiting several minutes for a runner is normal, and that delay lands on every developer, every push.
Caching is where the real speedup lives
Persistent local NVMe changes CI economics more than raw core count does. Docker layers, Cargo registries, node_modules, Gradle caches and ccache all survive between runs on a self-hosted runner, where a hosted runner starts clean and re-downloads everything.
For a large Rust or C++ project this is frequently a five- to ten-fold reduction in wall-clock build time, and it is entirely free.
Isolation, because runners execute arbitrary code
A self-hosted runner runs whatever is in the pipeline, which for a public repository means whatever a contributor puts in a pull request. Never attach a self-hosted runner to a public repository without ephemeral, isolated execution.
Use ephemeral runners in containers or short-lived VMs, give the runner no credentials it does not need, and put it on a server with nothing else on it. A $14 machine per project is cheap insurance against a compromised pipeline reaching the rest of your infrastructure.
Frequently asked questions
01 Which plan for a CI runner?
VECTOR (4 vCPU, 8 GB) for a typical project; BASTION (6 vCPU, 16 GB) for a monorepo or heavy compilation. Persistent NVMe cache matters more than core count for most pipelines.
02 Does it work with GitHub Actions?
Yes. Register the machine as a self-hosted runner and target it with runs-on. GitLab, Forgejo, Woodpecker and Drone all work the same way.
03 Is a self-hosted runner safe for public repos?
Not without ephemeral isolation. A pull request can run arbitrary code on the runner. Use ephemeral containers or throwaway VMs, and never grant credentials the pipeline does not need.
04 How much faster is it?
Typically two to four times on raw compute, and five to ten times on cache-heavy pipelines because Docker layers and dependency caches persist between runs instead of being re-downloaded.
Related