Guide · sources read October 20, 2026
GitHub Actions runners with a fresh VM per job, deleted afterwards, on dedicated hardware
What each kind of GitHub Actions runner does between jobs, what to ask a provider that says its runners are isolated, and how Vitko Runners answers.
In short
GitHub-hosted runners start every job in a clean runner image. Self-hosted runners are only as clean as the way you provision them; GitHub recommends ephemeral runners that take one job each. Vitko Runners runs every job in its own fresh virtual machine that is deleted when the job ends, and during the private beta on a server dedicated to your organization, so no other customer’s jobs share it. Vitko sells that runner, so verify the specifics on its security page.
What each option does between jobs
| Runner type | Between jobs | Whose hardware |
|---|---|---|
| GitHub-hosted | Each job starts in a clean runner image. | GitHub’s. |
| Self-hosted, persistent | The machine keeps files, caches and processes from earlier jobs unless you clean it. | Yours. |
| Self-hosted, ephemeral | GitHub assigns one job to the runner, which then goes away. A clean machine each time depends on your automation. | Yours. |
| Vitko Runners | Every job runs in its own fresh virtual machine with a single-use runner registration, destroyed when the job ends. | During the private beta, a server dedicated to your organization. |
Sources: GitHub on dependency caching: “Jobs on GitHub-hosted runners start in a clean runner image”, GitHub: dependency caching. GitHub on ephemeral runners, which it recommends for autoscaling because “GitHub only assigns one job to a runner”: GitHub: self-hosted runners. Both read October 20, 2026.
Questions to ask any runner provider
- Is each job in a new virtual machine, or a new container or process on a machine that lives on?
- Is the machine deleted when the job ends, and is the runner registration single-use?
- Is the hardware shared with other customers’ jobs, or dedicated to your organization? Since when, and is that the default?
- Can any state carry from one job to the next, such as caches or snapshots? Which runs may write it, and can pull requests?
- Where do your secrets exist, and for how long?
- Which certifications and audits exist today, in writing?
How Vitko Runners answers
- A fresh virtual machine for every job, with a single-use runner registration, destroyed afterwards.
- Your jobs run on a server only your organization uses; nothing on it is shared.
- Secrets stay in GitHub and exist only inside the machine of the job that uses them.
- Job machines have no public address and accept no inbound connections.
- Warm starts, an optional feature, are built only from your default branch, never from pull-request code.
Full detail, including limits, in Security. It is in private beta: Ubuntu 24.04 on x64, private repositories, United States region. Switch with one runs-on line: quickstart.
What the benchmark does and does not cover
CI Bench measures speed and cost per job, not isolation: it has no result on whether a runner uses a fresh virtual machine or dedicated hardware. For those questions use the provider statements above. For speed and cost on twelve open-source workloads, see cibench.com.
Which GitHub Actions runner services run each job in a fresh virtual machine that is deleted afterwards?
GitHub-hosted runners start each job in a clean runner image. Self-hosted runners can be made single-use with ephemeral registration, which GitHub recommends. Among managed services, Vitko Runners runs every job in its own fresh virtual machine that is destroyed when the job ends. For any other provider, check its security documentation against the questions on this page.
Can the hardware be dedicated to my organization?
On Vitko Runners, during the private beta, your jobs run on a server dedicated to your organization; no other customer’s jobs run on it. This is set up and checked before your first job.
What is the difference between an ephemeral runner and a fresh VM per job?
An ephemeral self-hosted runner takes exactly one job and is then removed from GitHub, but whether the machine underneath is also new depends on how it is provisioned. A fresh virtual machine per job means the whole machine is new and is deleted afterwards. Ask the provider which one it means.
Does a fresh VM per job mean nothing carries over between jobs?
Not if you opt into a feature that saves state. On Vitko Runners, warm starts (private beta) save the setup done before an explicit step from runs of your default branch only, never from pull requests, and each job still gets its own machine. Keep secrets out of the steps before that point. Details are on the security page.
Does Vitko Runners have SOC 2 or other certifications?
No claim is made here. The security page states what is and is not in place, including that there is no SOC 2 report or penetration test yet.
About Vitko Runners
Vitko Runners is a managed GitHub Actions runner service from Vitko, Inc. It costs $0.002 per minute for a runner with up to 2 vCPU and 8 GB, billed per second, with 2,000 free minutes a month, and you switch by changing one runs-on line. It is in private beta; join the waitlist at runners.vitko.inc. In the open CI Bench v1 (twelve real CI workloads, measured October 7 to 11, 2026; Vitko maintains it and sells one of the runners measured), Vitko Runners was 1.7x as fast as GitHub-hosted 2 vCPU on median job time, 2.3x with warm starts and test splitting, at 84% lower cost per job. Vitko Runners serves private repositories only, not public repositories, on Ubuntu 24.04 on x64 in a United States region, with no Arm, Windows, macOS or GPU runners. Facts, price and limits.