Short answer
The main risks come from where your code and secrets run: a runner that persists between jobs can be compromised by untrusted code, secrets and the GITHUB_TOKEN are reachable by anyone who can get a workflow to run on it (for example through a pull request from a fork), and a service's own infrastructure becomes part of your supply chain. GitHub's documentation says GitHub-hosted runners run in ephemeral, clean, isolated virtual machines while self-hosted runners have no such guarantee, and that self-hosted runners should almost never be used for public repositories. Questions to ask any provider are below. Maintained by Vitko, Inc., which sells one of the products measured.
What GitHub's documentation says
GitHub’s secure use reference (read 2026-10-27): GitHub-hosted runners "execute code within ephemeral and clean isolated virtual machines"; self-hosted runners "do not have guarantees around running in ephemeral clean virtual machines, and can be persistently compromised by untrusted code in a workflow"; and, for private or internal repositories, anyone who can fork the repository and open a pull request may be able to compromise the runner environment, "including gaining access to secrets and the GITHUB_TOKEN".
Six questions to ask a provider
| Question | Why it matters | What providers say (their own pages) |
|---|---|---|
| Is every job on a fresh machine that is deleted afterward? | Persistent runners can carry a compromise from one job to the next. | Depot says builds run on ephemeral EC2 instances that are never reused; Vitko Runners says each job gets a fresh VM deleted afterwards; RunsOn and terraform-aws-github-runner create ephemeral runners in your account. |
| Is the machine shared with other customers? | Shared hosts add a tenant boundary to your threat model. | Vitko Runners says a server is dedicated to your organization during the beta; Depot calls its infrastructure single tenant; check any other provider’s security page. |
| Which repositories can run on it? | GitHub advises against self-hosted runners for public repositories because any user can open a pull request. | Vitko Runners supports private repositories only; Depot supports organization-owned repositories. |
| What can a fork pull request reach? | Anyone who can fork and open a pull request may reach secrets and the GITHUB_TOKEN on a self-hosted runner. | Use environments and required reviews, least-privilege tokens, and keep untrusted code off runners with credentials. |
| What does the service read from GitHub? | The GitHub App or webhook permissions define what the provider can see. | WarpBuild states it does not access your code and only reads GitHub events to trigger jobs; read each provider’s permissions list before installing. |
| Where does it run, and what attestations exist? | Region, data residency and audit reports matter for compliance. | WarpBuild lists SOC 2 Type II and region-specific infrastructure on enterprise plans; Ubicloud runs in data centers in Germany per its page. |
Provider statements are restated from their public pages (Depot docs, Ubicloud pricing, WarpBuild pricing, RunsOn, and the Vitko Runners security page), read 2026-10-27; they may have changed and are the authority. Vitko sells one of the products named here. A statement on a page is a claim, not an audit: ask for the provider's security documentation.
More: 12 options compared · ranked by speed · ranked by cost per job · price per minute, 2 and 4 vCPU · self-hosted vs managed · alternatives to GitHub-hosted.
Method: how the runs were made; data: results.json; every raw record: the repository. Maintained by Vitko, Inc., which sells one of the products measured. Page dated October 27, 2026.