compiler.dev vs GitHub-hosted runners

GitHub-hosted runners are the default for GitHub Actions: you write runs-on: ubuntu-latest and GitHub gives your job a fresh virtual machine. compiler.dev runs the same jobs on faster machines. You keep your workflows, your checks and your pull request flow; only the machine changes. This page compares the two on price, speed, setup and risk, using GitHub's own published prices.

The short answer

If your CI finishes in a minute or two and nobody waits on it, GitHub-hosted runners are fine and cost nothing extra to set up. If your team waits on CI several times a day, or you already pay for GitHub's larger runners, compiler.dev gives you 4× the CPU of GitHub's 2-core runner; per minute it costs more, per run often less. On our measured stacks, full CI runs were a median 1.5× faster across 18 measured stacks (15 faster, 2 the same, 1 slower) than on ubuntu-latest. See the benchmarks for the method and every result, including the ones that were not faster.

Price per minute

GitHub's standard Linux runner (ubuntu-latest) has 2 vCPUs and costs $0.006 a minute on private repositories, after your plan's included minutes. GitHub's 8-core larger runner costs $0.022 a minute, with no included minutes, and needs a Team or Enterprise Cloud plan. compiler.dev's default machine has 8 vCPUs and 16 GB of memory and costs $0.012 a minute on the Basic plan. The Pro plan costs $0.014 a minute for 8 vCPU ($0.0035 a minute for 2 vCPU) and runs on warm machines, which are machines with your dependencies pre-installed.

So an 8 vCPU minute costs about 45% less than GitHub's 8-core runner. Against ubuntu-latest you get 4× the CPU of GitHub's 2-core runner; per minute it costs more, per run often less, because jobs that use several cores finish sooner. Our benchmark table shows the cost per run for each stack. For a full list of providers, see the runner price table.

What changes in your workflow

One line per job. Everything else stays as it is. After you install the compiler.dev GitHub App, runs-on: compiler-8cpu (also compiler-2cpu, compiler-4cpu, compiler-16cpu) runs the job on compiler.dev.

jobs:
  test:
    # before
    # runs-on: ubuntu-latest
    runs-on: compiler-8cpu
    steps:
      - uses: actions/checkout@v4
      - run: npm ci && npm test

The older [self-hosted, Linux, compiler-ci] label still works. Or use the setup in the app, which opens a pull request for you. Each routed workflow gets a small route job that asks compiler.dev where to run, so you can move a share of jobs at a time and compare the times before switching fully. The docs walk through it.

Reliability and fallback

The main worry with any third-party runner is what happens when it fails. With the routed setup, if compiler.dev cannot take a job, or your credit or monthly cap runs out, the job runs on the runner it used before you switched, whether that is GitHub-hosted or your own. Your CI keeps working; it just runs at the old speed. If you use a size label such as compiler-8cpu directly, there is no automatic fallback: the job waits for a compiler.dev runner. Deploy jobs never move, only Linux build and test jobs. To undo the switch, set the share to 0% or revert the setup pull request.

GitHub-hosted runners have no extra moving part, which is their main advantage. They also share GitHub's outages: when GitHub Actions is degraded, hosted jobs queue or fail. compiler.dev watches GitHub's status page and, once an incident is resolved, re-delivers missed webhooks and re-runs the jobs that failed because of it. You can follow GitHub's current state on our GitHub status page.

Caches and machine

Both give you a fresh virtual machine per job, deleted afterwards, so one job cannot leak state into the next. On GitHub-hosted runners you set up caching yourself with actions/cache, and Docker layers are rebuilt unless you add a cache backend. compiler.dev machines come with dependency, git and Docker layer caches ready, and support Nx and Turborepo remote caching. Read more in our guides on GitHub Actions caching and Docker layer caching in CI.

Payment

GitHub bills Actions minutes through your GitHub plan: included minutes first, then usage. compiler.dev starts with 200 free minutes (a card is needed, and you set a monthly limit), then prepaid credit. You prepay credit from $20. Usage is drawn down per minute and you get a monthly statement. Credit never expires and unused credit is refundable on request. When credit reaches zero, routed jobs run on your previous runners again; jobs with a size label wait. Details are on the pricing page; you can estimate your own bill with the savings calculator.

When GitHub-hosted runners are the better choice

• Public repositories: standard GitHub-hosted runners are free for them.
• Very short jobs that are single-threaded, where more cores do not help.
• Windows jobs: compiler.dev runs Linux today, with macOS in early access.
• Teams that cannot add any third-party app to their GitHub organization.

FAQ

Is compiler.dev cheaper than GitHub-hosted runners?

Per minute, yes for every size GitHub sells larger runners in: $0.012 against $0.022 for 8 vCPU Linux. Against the 2 vCPU ubuntu-latest at $0.006 you get 4× the CPU; per minute it costs more, per run often less, depending on how well your jobs use the cores.

Do I need to rewrite my workflows?

No. You change the runs-on line of the jobs you want to move (for example to compiler-8cpu). Steps, actions, secrets and checks stay the same.

What happens if compiler.dev is down?

With the routed setup, jobs run on your original runners automatically, so CI keeps working: the route job decides where each job runs, and any error sends it back to the original runner. With a size label such as compiler-8cpu there is no automatic fallback; the job waits for a compiler.dev runner.

How do I compare speed on my own repository?

Use comparison mode in the app: a copy of your jobs runs on our machines while your results still come from your own runners. You see both times side by side before switching anything.