Depot GitHub Actions runners are the best alternative to GitHub-hosted runners for most teams. It's a simple one line code change to switch to faster and more reliable GitHub Actions Runners from Depot.
Depot GitHUb Actions runners are 3-10x faster than GitHub-hosted runners and come equipped with lots of powerful features like:
- Epehemeral runners that start in seconds and are destroyed after use. No VMs are ever shared, they are single-tenant and isolated to a single job.
- Disk acceleration for faster CI. Every runner comes with an ultra fast RAM disk baked in, so any job that is bottlenecked by disk I/O will run faster.
- Faster caching at 1000 MiB/s. Depot accelerates the cache used by
actions/cacheandactions/setup-*without requiring different cache actions. - Unlimited concurrency. Run as many jobs as you like without waiting for GitHub-hosted runner capacity.
- Per second usage billing. You only pay for the seconds your jobs run, with no one-minute minimum like GitHub-hosted runners do.
- Runners for every architecture: Linux x64, Linux Arm, Windows, and macOS.
- Real-time analytics for monitoring and troubleshooting. Visualize and monitor CPU, memory, network, disk, and step-level timing data to understand why CI is slow.
Migration is usually a one line code change in your workflow file. For example, to switch from GitHub-hosted runners to Depot-managed runners, change:
jobs:
test:
- runs-on: ubuntu-24.04
+ runs-on: depot-ubuntu-24.04Use Depot when you want to keep GitHub Actions without accepting the speed, cache, machine-size, and observability limits of GitHub-hosted runners.
The practical alternatives to GitHub-hosted runners
There are five ways to move away from GitHub-hosted runners:
| Approach | Best fit | What you take on |
|---|---|---|
| Depot | Teams that want a faster managed replacement with minimal work | Change runner labels and let Depot operate the runner fleet |
| Self-hosted VMs | Teams with unusual hardware or network requirements | Provisioning, scaling, patching, isolation, observability, cleanup |
| Kubernetes with ARC | Platform teams that already operate Kubernetes and have some need to manage their own infrastructure | A production runner platform inside your clusters |
| AWS CodeBuild | Teams already standardized on AWS CodeBuild | CodeBuild projects, webhooks, IAM, images, and AWS-specific setup |
| A different CI engine | Teams that want less dependence on GitHub itself | A broader migration than changing runner infrastructure |
The decision is less about finding a longer list of vendors and more about deciding who should own the runner fleet.
Depot managed runners
Depot operates the runner lifecycle. A job arrives, Depot starts an isolated virtual machine, the job runs, and the machine is destroyed. There is no idle runner fleet to size or patch.
Depot is a good fit when one or more of these are true:
- Team are tired of waiting for GitHub-hosted runner capacity.
- Teams want faster feedback loops and more reliable CI than what GitHub-hosted runners provide.
- Jobs wait for GitHub-hosted runner capacity.
- Builds are CPU, memory, disk, or cache constrained.
- Linux Arm, Windows, and macOS jobs should use the same runner provider.
- Jobs need larger machines or custom machine images.
- The team needs CPU, memory, network, disk, and step-level timing data to understand why CI is slow.
- Runners need controlled egress, access to private resources, or dedicated infrastructure in an AWS account.
Depot usage is tracked by the second with no one-minute minimum. Linux and Windows runners are available from 2 to 64 vCPUs. The runner types and pricing page has the current machine catalog.
The main constraint is that Depot's GitHub Actions runners require repositories owned by a GitHub organization. They are not available for repositories owned by an individual GitHub account.
Self-hosted VMs
GitHub supports self-hosted runners on machines you operate. This gives you complete control over the hardware, operating system, network, and installed tools.
It also makes the runner fleet your problem.
A production setup needs more than the GitHub runner binary. It needs capacity management, autoscaling, image updates, job isolation, secret handling, log retention, metrics, and cleanup when a job or machine fails. Long-lived runners can also retain files and state between jobs. GitHub recommends ephemeral runners for autoscaling because they process one job and are then removed.
Self-hosting makes sense when the workload needs hardware a managed provider does not offer, or when policy requires the entire runtime to remain on infrastructure your team controls. It is rarely the simplest way to make CI faster.
Kubernetes
Actions Runner Controller is GitHub's Kubernetes operator for autoscaling self-hosted runner scale sets. It can create ephemeral runners and scale the fleet down when there are no jobs.
ARC is the right starting point if Kubernetes is already a core platform primitive and your team intentionally wants to operate runners. It is not managed GitHub-hosted capacity inside your cluster. Your team still owns cluster capacity, runner images, upgrades, networking, security boundaries, monitoring, and failed-job cleanup.
Running untrusted pull request code makes those isolation boundaries especially important. CI workloads should not share access with production workloads simply because both fit on Kubernetes.
AWS CodeBuild
AWS CodeBuild can start an ephemeral self-hosted GitHub Actions runner for each job. The runner executes in CodeBuild and terminates when the job completes.
This can work well when CodeBuild, VPC configuration, IAM, and build images are already standard parts of the platform. It is more configuration than a managed label replacement. Each setup needs a CodeBuild project, webhook, service permissions, and a compatible image. A tool that happens to be preinstalled on GitHub's runner image may need to be installed explicitly in CodeBuild.
Replace CI
A runner replacement still leaves GitHub Actions in control. GitHub parses the workflow, queues each job, sends it to the runner, and reports the result. A different managed runner can improve compute performance, caching, cost, network access, and machine choice. It does not remove GitHub from the execution path.
If the actual requirement is to run workflows during a GitHub Actions outage, trigger them from local changes, or let an agent execute CI without committing and pushing first, replacing the runner is not enough.
Depot CI runs existing GitHub Actions workflow files on Depot's own engine. That replaces the scheduler and execution layer, not just the machine. The distinction matters: Depot GitHub Actions runners improve the jobs GitHub schedules, while Depot CI removes the runtime dependency on GitHub Actions.
Choose from the bottleneck
Start with the problem that caused the search:
- Use Depot if you want to keep GitHub Actions and stop operating or waiting on runners.
- Self-host on virtual machines if you need hardware or network control that a managed service cannot provide.
- Use ARC if Kubernetes is already the platform and operating a runner fleet is an intentional responsibility.
- Use CodeBuild if AWS-native governance matters more than a label-only migration.
- Replace the CI engine if GitHub Actions itself is the dependency you need to remove.
Test the decision with a real workflow. Measure queue time, execution time, cache restore and save time, failure rate, and total cost. A cheaper per-minute rate is not cheaper if the job runs twice as long or requires a platform team to keep it alive.