I Migrated Our CI Off Standard GitHub Runners. Here’s the Before and After.

GitHub Actions has been genuinely good to build on. The YAML is simple enough to write from memory after a week; the marketplace covers almost anything you’d want to bolt onto a pipeline, and CodeQL scanning came along for free without anyone on the team having to ask for it. None of what follows is really about GitHub Actions being wrong. It’s about what happens once you outgrow the default compute sitting underneath it.

Our pipeline runs on GitHub-hosted ubuntu-latest runners, 2 vCPUs and 7 GB of RAM, shared with every other job GitHub is running that minute. That’s fine at ten builds a day. It stops being fine once a team of a dozen engineers, plus a growing set of agents opening their own pull requests, are pushing dozens of times a day and every one of them is waiting on the same queue. So I looked into what else was out there, evaluated a handful of GitHub Actions alternatives, and ended up migrating our production CI to Avrea. Here’s what the pipeline looked like before, what changed, and what the numbers actually showed.

What Our CI Pipeline Looked Like Before the Switch

Our stack is a TypeScript monorepo on the frontend, a Go service on the backend, and a Docker build stage that packages both for deployment. Nothing exotic, which is part of the point: this is close to what most mid-sized teams are running.

Three things were consistently frustrating on standard runners:

• Queue time. Jobs didn’t start the moment they were triggered. Most mornings, when the whole team pushed within the same half hour, jobs sat waiting for a runner to free up, sometimes for four minutes or more before a single line of our workflow had run.
• Docker build variance. The same Dockerfile, same layers, same base image, and build times ranged from 3 to 6 minutes depending on which shared host we landed on.
• No visibility into any of it. GitHub’s UI shows a log and a green or red checkmark. It doesn’t show step-level timing, resource usage, or whether a failure is a real bug or a flaky test that’s failed four times this month.

None of these are unique to us. They’re the standard complaints that eventually push a team to look elsewhere, and they’re exactly what “GitHub Actions alternatives” as a search term is usually standing in for.

Looking at the Wider Field of GitHub Actions Alternatives

Once queueing and flakiness become a weekly conversation, the alternatives fall into two broad categories, and it’s worth being clear-eyed about both before picking one.

Self-hosted runners (commonly run through Kubernetes’ Actions Runner Controller on your own AWS, GCP, or Azure capacity) give you full control over hardware and no per-minute markup. The tradeoff is that you now own patching, scaling, and security updates for a fleet of build machines, which is a real ongoing job, not a one-time setup.

Managed drop-in replacements keep the GitHub Actions workflow syntax exactly as-is and just swap the runner underneath. This is the category Avrea sits in, alongside names like Blacksmith, Depot, Namespace, and WarpBuild. They mostly compete on the same few axes:

We ruled out self-hosting early. Nobody on a twelve-person team wanted to become the on-call person for a runner fleet on top of everything else. That narrowed the search to the managed category, and from there it came down to actually running our own workflow on each candidate rather than comparing marketing pages.

Why We Landed on Avrea Over the Other Options

Three things decided it, in order of how much they actually mattered day-to-day.

Migration cost came first, because we weren’t going to rewrite our pipeline to evaluate five different vendors. Avrea’s setup is a GitHub App install plus a one-line change to the runs-on label, avrea-ubuntu-latest, matching GitHub’s own default of 2 vCPUs and 8 GB, so we could duplicate our existing workflow, point the copy at Avrea, and run both side by side without touching anything else.

Bundling came second. Several of the alternatives are strong at one thing; Depot, for instance, leans hard into Docker build acceleration, but we needed compute, dependency caching, and some actual visibility into what was slow, all in the same place, without stitching together three vendors and three sets of credentials.

Get Shyam’s stories in your inbox

Join Medium for free to get updates from this writer.

Remember me for faster sign in

Cost came third, mostly because it stopped mattering as much once the first two were solved. Avrea’s published rate starts at $0.002/min for a 1-vCPU Linux runner, scaling predictably with core count, with 3,000 free minutes per month to test against. Combined with faster builds, that’s a lower number on both sides of the equation: cheaper per minute, and fewer minutes billed.

Running the Actual Migration Side by Side With GitHub

The migration itself took three steps, and none of them touched our actual build logic.

1. Install the Avrea GitHub App on our organization and grant it access to the one repo we were testing against.
2. Duplicate the workflow file, changing only runs-on: ubuntu-latest to runs-on: avrea-ubuntu-latest in the copy, and leaving the original untouched so we had a direct comparison.
3. Trigger both workflows back-to-back. The first run showed the raw hardware difference. The second run, once the dependency cache had something to restore from, showed the bigger gap.

jobs:
  build:
    runs-on: avrea-ubuntu-latest
    steps:
      - uses: actions/checkout@v6
      - uses: actions/setup-node@v6
        with:
          node-version: 24
          cache: 'npm'
      - run: npm ci
      - run: npm run build
      - run: npm test

We ran the two pipelines in parallel for about a day before cutting production traffic, which is roughly the same timeline that other teams making this switch have reported.

Comparing Build Times Before and After the Switch

Averaged across a week of real merges, not a synthetic benchmark, our own numbers landed like this:

That’s roughly a 2.2x speedup in median build time, closer to the low end of what Avrea’s own hardware benchmarks claim (2–3x on cold runs before caching even factors in), and a 73% reduction in the CI bill, close to Avrea’s published up to 75% cheaper figure.

We weren’t the only ones to see this shape of result. Avrea’s own published case studies show the same pattern across very different stacks: a Turborepo monorepo team went 2x faster and dropped a separate remote cache vendor entirely after switching over. An e-commerce content platform cut job times roughly in half, from six minutes to three. A marketing automation team reduced build times from around 4 minutes to 42 seconds. A developer-tools company that had already been running on a different GitHub Actions alternative saw test feedback get 27% faster at the median even as their test suite grew by 22%, with jobs picked up in a median of 16 seconds instead of sitting in a queue.

What We Gained Beyond Raw Speed

Speed was the reason we looked, but the parts we didn’t expect to care about ended up mattering just as much.

• Step-level logs that stay searchable. Every step in every job gets its own collapsible log with full-text search, live tail while the job runs, and rendered ANSI colors instead of raw escape codes.
• A 30-day view of flake and failure rate. Jobs that fail on a step that passed elsewhere in the same run are automatically flagged as flaky, rather than us manually noticing a test that kept failing.
• SSH into a running job. When something breaks in CI, but not locally, we can drop into the exact VM the job is running in and poke around, instead of adding echo statements and re-pushing.
• One less vendor to manage. The 25 GB of cache storage and the build-cache adapters for tools like Turborepo and Docker layers are built into the runner image, so we didn’t need to keep a separate caching service configured and paid for on the side.

None of this shows up in a “3x faster” headline, but it’s the difference between finding out why a job is slow in two minutes versus an afternoon of guessing.

Where This Migration Made Less Sense For Us

To be fair to the other side of this: a small repo with a handful of jobs a day wouldn’t have felt any of the queueing pain that started this search, and the migration wouldn’t have been worth the (admittedly small) effort of testing it. Avrea also only supports GitHub Actions today, so a team split across GitHub and GitLab would need to keep evaluating the GitLab side separately until that support lands. And if your team has already sunk real engineering time into a self-hosted ARC setup that’s working fine, ripping that out for a managed alternative is a bigger conversation than the one-line change described above.

What to Look at Before Making the Same Move

Everything above came from actually running our own repo twice, once on the runner we’d always used and once on the alternative, rather than trusting a comparison chart. That’s really the only way to evaluate any of these tools honestly, ours included.

If any of the “before” section sounded familiar, the cheapest first step is checking your own numbers: how long jobs actually sit in queue before starting, and what your Docker build time actually looks like across a week instead of one lucky run. Both are usually visible right in the Actions tab, and both told us more than any competitor’s pricing page did.

From there, testing an alternative costs nothing more than a duplicated workflow file and a day spent running them side by side, which is exactly how we made this decision. Avrea’s free to try on your own repo, or talk to their team directly if you’d rather walk through your specific setup first.

The bigger shift for us wasn’t really the runner. It was realizing how much of our CI time we’d been treating as fixed, when most of it was just the cost of never having looked closely enough at where the minutes were actually going.