Hosted CI minutes are convenient right up until the invoice arrives. If your pipelines build containers, run integration suites, or compile anything non-trivial, the per-minute meter on managed runners adds up fast — and you're paying for cold caches on every run. A VPS for GitHub Actions self-hosted runner work flips that model: you spin a machine for the duration of a pipeline, warm the cache on local NVMe, tear it down, and pay for the wall-clock seconds it lived. This is a notes-from-the-rack look at when that math wins, and how we bill it.
Running a GitHub Actions self-hosted runner on a VPS
A self-hosted runner is just a box that registers with GitHub Actions (or a GitLab runner that registers with your project) and picks up jobs. The appeal is control: your own CPU, your own disk speed, your own base images already pulled, and no per-minute meter on the vendor side. The catch has always been that a runner sitting idle 20 hours a day is a rented server you're not using. Hourly billing removes the catch. On our Hourly VPS the meter runs to the second, from EUR 0.0056/hr, so an idle runner isn't a monthly line item — it's a machine you don't keep alive between pipelines.
The pattern that pays off: a controller (a scheduled job, a webhook, or a small script hitting our API) creates a VPS when a pipeline is queued, the runner registers, does the work, deregisters, and the box is destroyed. You're billed for the minutes it existed. For a team pushing a few dozen builds a day, that's a fleet of ephemeral runners whose combined cost is a rounding error next to a fixed managed-CI plan.
The cost math: cents per pipeline
Let's make it concrete with the entry tier. VPS I is 2GB RAM / 1 vCPU / 40GB NVMe at EUR 4/mo, which is EUR 0.0056/hr billed to the second. A ten-minute pipeline on that box costs you about a tenth of a cent of compute. Run a hundred of those in a day and you're at roughly ten cents. The popular VPS II (4GB / 2 vCPU / 80GB) at EUR 6/mo suits heavier builds — container assembly, a Node or Rust compile with a real test suite — and still lands in a fraction of a cent per minute.
The comparison that matters is against hosted CI minutes. Managed runners typically bill a flat rate per minute regardless of how much of the machine you use, and they hand you a cold cache each run. Here's how we think about the break-even:
| Factor | Hosted CI minutes | Hourly self-hosted VPS |
|---|---|---|
| Billing granularity | Per minute, rounded up | Per second, from EUR 0.0056/hr |
| Cache | Cold or remote-fetched each run | Warm on local NVMe (persist the box across a burst) |
| Idle cost | None (but no persistence either) | None — destroy between pipelines |
| CPU/RAM you control | Fixed vendor allocation | Pick the tier that fits the job |
| Concurrency | Plan-capped, priced per lane | Spin as many boxes as you need, each billed to the second |
The rule of thumb we give teams: if your monthly hosted-CI minute spend is more than a couple of low tiers would cost to run on demand, self-hosting on hourly VPS almost always comes out cheaper — and it gets dramatically cheaper the moment your builds are cache-sensitive.
NVMe cache is where the real speedup lives
Per-minute pricing hides a second cost: the minutes you burn re-downloading dependencies and rebuilding layers because the cache lives somewhere else. Every tier we run is on NVMe, and that changes the shape of a pipeline. Dependency installs, Docker layer caches, compiler artifact caches, and test fixtures all sit on fast local disk. For a burst of pipelines against the same branch, keep one runner box alive for the burst so the cache stays warm, then destroy it when the queue drains — you pay for the burst, not the day.
The other half of the speed story is how fast a box appears. Our median deploy is 47 seconds, so an on-demand runner is available before a developer has finished reading the PR they just opened. That deploy latency is what makes ephemeral runners practical instead of theoretical — you're not waiting minutes for a machine, so the "create, build, destroy" loop stays tight.
Spinning runners up and down programmatically
None of this works if provisioning is a manual click. Every VPS ships with root SSH and full KVM virtualization, and we expose a REST API at my.noded.cloud/api/v1 for create/destroy. A typical setup is a small orchestrator — a workflow that calls the API to create a VPS, waits for SSH, runs a cloud-init script that installs the runner agent and registers it with a job-scoped token, then destroys the box when the job completes. Pick from 41 OS templates for the base image, bake your toolchain into a snapshot, and your cold-start is just the runner registration.
For GitLab runner VPS setups in Europe the flow is identical — register the runner against your instance instead of GitHub, tag it, and let your CI config target the tag. Because we run our own AS60982 backbone with 13 EU POPs and sub-5ms intra-EU latency, pulling from registries and package mirrors inside Europe stays fast, and the 1 Gbps unmetered symmetric link on every VPS means a chatty build downloading gigabytes of layers doesn't eat into a transfer cap.
Picking a tier for your pipeline
Match the box to the job rather than over-provisioning a permanent runner. Light lint-and-test pipelines are happy on VPS I or VPS II. Container builds and parallel test suites want the extra cores — VPS III (8GB / 2 vCPU / 120GB, EUR 10) or VPS V (16GB / 4 vCPU / 200GB, EUR 30). Monorepo builds that fan out dozens of jobs are better served by several small boxes running concurrently, each billed to the second, than one large machine sitting idle between waves. When a pipeline outgrows any VPS tier — think large compile farms or hardware-in-the-loop — that's the conversation for a dedicated server.
How Noded Can Help
We built our Hourly VPS around exactly this loop: create a runner, build, destroy, pay cents. Every VPS is hourly, billed to the second from EUR 0.0056/hr, on NVMe, with root SSH and a REST API so your workflow can manage the whole lifecycle without a human in it. Deploys land in a median of 47 seconds, so ephemeral runners feel instant, and our own AS60982 network keeps registry and mirror traffic fast across Europe. Start on VPS I to prove out the pattern, then size up per pipeline. If you want a hand wiring the create/destroy orchestration against our API, we're on-call.
FAQ
Is an hourly VPS really cheaper than hosted CI minutes?
For cache-sensitive or frequent builds, usually yes. Hosted runners bill per minute with cold caches; an hourly VPS bills to the second from EUR 0.0056/hr on warm local NVMe. If your monthly CI-minute spend exceeds the cost of running a couple of low tiers on demand, self-hosting typically wins.
How do I run a GitHub Actions self-hosted runner on a VPS?
Create a VPS via our API or panel, connect over root SSH, install the runner agent, and register it against your repo or org with a token. Scope it to a job, run your pipeline, then deregister and destroy the box so you only pay for the time it existed.
Can I spin runners up and down automatically?
Yes. The REST API at my.noded.cloud/api/v1 handles create and destroy, and every VPS has root SSH plus KVM. A small orchestrator can create a runner when a pipeline queues and tear it down when it finishes, so idle runners never cost you anything.
Does this work for GitLab runners too?
It does. The lifecycle is the same — provision the VPS, install and register the GitLab runner against your instance, tag it, and target the tag from your CI config. Our EU network keeps registry and mirror pulls fast for runners hosted in Europe.
Which VPS tier should a CI runner use?
Light test-and-lint jobs run fine on VPS I (2GB/1vCPU) or VPS II (4GB/2vCPU). Container builds and parallel suites want VPS III or VPS V for the extra cores. For fan-out monorepo pipelines, run several small boxes concurrently rather than one idle large one.