runs-on: mac

Once upon a time, in the land of software development, a magical practice called Continuous Integration was invented. It was a tool to help developers integrate their changes through trunk-based development, weaving together code like threads in a grand tapestry. And lo, companies emerged to solve this challenge, building great machines to run the builds and tests that kept the kingdom's software safe and sound. Research would later show that elite performers were 2.3 times more likely to use these practices, but that's getting ahead of the story. But there was a dark secret: hosting Mac Minis was damn hard. (Spoiler: it still is.) These mysterious silver boxes required special care, specific environments, and a level of infrastructure magic that made even the bravest engineers tremble.
Some wise companies decided to focus on the mobile space, at least in their marketing scrolls. They spoke of iOS and Android as if they were unique realms requiring special tools. But the truth was, beneath the banners and proclamations, all their products were fundamentally the same: pipeline processing, environment orchestration, reporting of results, and caching. The same magic, packaged in different boxes. In this era, a company called BuddyBuild rose to prominence. But their story took an unexpected turn when they were acquired by Apple in 2018, disappearing behind the great walled garden, their tools absorbed into the empire's private chambers.
And so began a dark age. The incentives to innovate in mobile CI were low. The market was smaller than other ecosystems, and hosting those cursed Mac Minis remained a pain. This resulted in just a few players who poured all their power into sales and marketing machines, consequently atrophying their products. The land of mobile CI barely saw any innovation. It was just the same solution, packaged differently. The whole game became about who could push prices down. Some companies built their own infrastructure to have more cost control, but innovation? None. Zero. Zilch. The kingdom stagnated while its merchants grew fat on promises rather than progress. I, dear reader, love innovation. I want to see more of it, not less. And this stagnation made me terribly, deeply uncomfortable.
But markets happened. And this, dear reader, is the beauty of capitalism. In October 2018, GitHub introduced GitHub Actions, and GitLab had already introduced its CI capabilities back in November 2012. Other Git forges followed suit, each adding their own flavor of automation magic. But here's where the story gets interesting: they sliced CI horizontally, separating the "frontend" (the pipeline definitions, the orchestration) from the "backend" (the environments where builds actually run). It was like separating the conductor from the orchestra, allowing different musicians to play the same sheet music. And that gave birth to a new market: companies that just provide the runners. With a beautiful twist, moving across these companies was as easy as changing one line in your pipeline configuration. One line! Just change "runs-on" (hence the name of this very website you're reading), and suddenly you're free. These new companies had a stronger incentive to build better and cheaper products. Since that day, I've witnessed a renaissance, with amazing and competitive products finally helping organizations escape the imaginary "vendor lock-in" that mobile CI companies had been selling, moving to a lower layer with better products and more competitive pricing.
These same companies that solved environments for CI found themselves at the dawn of a new era. They began solving environments for agentic coding tools, whose workload could mimic, if not exceed, the demanding nature of CI builds. And so they grew stronger, getting better and better at providing reliable environments fast. Meanwhile, the old mobile CI companies did their best to stay afloat, decorating their aging infrastructure (in which they had invested for many years) and rebranding it as "Mobile DevOps" or other shiny new terms. But the world had changed. The runners had won.
In this new world, depending on CI-coupled solutions became a dangerous proposition. Why? Because it became increasingly important that solutions and services were decoupled from specific environments. Development no longer happened only on CI. It happened on developers' local environments, in cloud development environments, and in remote agentic coding tool environments. The walls between "CI" and "development" were crumbling. Yet some companies tried harder and harder to couple their environments with other solutions built upon their vertical stack. Proprietary optimization tools, custom caching layers, vendor-specific integrations. But this was a mistake in such a fluid space. What we needed were environment-agnostic solutions that agents, pipelines, and developers could all access, regardless of where the code runs. Tools like Mise and portable bash scripts showed the way forward: automation that works everywhere. On your laptop, in CI, in an AI coding environment. The same commands, the same setup, the same reliability. This was the true meaning of decoupling. It became more important than ever that you, dear developer, gain back the agency of your automation. That you help the ecosystem move forward by adopting runners from companies dedicated to building a strong, reliable layer upon which innovation can flourish again.
And so, dear reader, I arrive at the present day. You stand at a crossroads. Will you continue to let your tools be coupled to aging platforms that prioritize sales over innovation? Or will you embrace the new world of decoupled runners, where changing providers is as simple as editing a single line? The choice is yours. But know this: by choosing freedom, by choosing the runner layer, you're not just making a technical decision. You're voting for innovation. You're helping to build an ecosystem where the best products win, not the ones with the biggest marketing budgets. You're helping to ensure that the next generation of developers will inherit a world where tools are composable, where vendor lock-in is a relic of the past, and where innovation flourishes because competition is real and meaningful.
And they all lived happily ever after... or at least, they had the freedom to choose their own happiness.

One Line. Infinite Freedom.

.github/workflows/build.yml
Namespace
Cirrus
WarpBuild
Blaze
Depot
MacStadium
name: Build iOS App

on:
  push:
    branches: [main]

jobs:
  build:
    runs-on: namespace-profile-default-arm64

    steps:
      - name: Checkout code
        uses: actions/checkout@v4

      - name: Build with Xcode
        run: xcodebuild build -scheme MyApp -configuration Release
Switch providers by changing one line. That's it.
Ah, dear reader, you raise the very question that proprietary CI platforms want you to ask. They've built their moats not with superior technology, but with proprietary step marketplaces and custom YAML syntax designed to make leaving painful. But here's the beautiful irony: the same technological revolution that gave birth to agentic coding tools has demolished these walls. With the help of AI-powered coding assistants, migrating to GitHub Actions has never been easier. A few tokens is all you need to escape the proprietary steps marketplace and bring your project the freedom it's been asking for. What once took weeks of manual translation—converting custom pipeline syntax, finding equivalent actions, rewriting proprietary steps—now takes minutes. Your AI assistant can analyze your existing CI configuration, translate it to GitHub Actions YAML, and even suggest modern, maintained alternatives from the vast open-source Actions ecosystem. The migration barrier has crumbled. The only question remaining is: when will you take that step?

Mac Runner Providers

Disclaimer: I list Namespace.so first because I use them. They are currently the only provider with a programmatic interface/API to build upon, and their product and team are amazing to work with. The other providers listed below are also excellent choices depending on your specific needs.
Note: Provider descriptions are derived from their websites and may become outdated. If you notice outdated information or would like to add new providers, please open a pull request to this repository.

Namespace.so

Purpose-built infrastructure for build and test workloads with native Apple Silicon support (M4 Pro and M2 Pro). Offers a programmatic API, remote SSH/VNC debugging, built-in observability, and SOC 2 Type II compliance. Flat-rate pricing based on concurrent jobs with unlimited minutes.

Cirrus Runners

Managed large runners featuring macOS M4 Pro with proprietary virtualization technology. Fixed monthly pricing with unlimited minutes and limited concurrency. Recently achieved #1 performance rating for x64 machines according to independent benchmarks.

WarpBuild

High-performance runners supporting Linux, Windows, and macOS (M2 Pro). Offers 50-90% cost savings compared to official runners with 25-70% reduction in build times. Features 150GB disk storage, unlimited fast caches, and live SSH debugging. Available as managed service or self-hosted.

Blaze

High-performance runners with Apple Silicon, Linux ARM64, and x64 support. Fixed monthly pricing at $149 with unlimited usage. Claims up to 3x faster performance than GitHub runners with comprehensive monitoring dashboard and analytics. Reports average 47% reduction in build times.

Depot

Supports macOS M2 builds with per-second billing and unlimited cache storage. Half the price of hosted GitHub runners with fast container builds and remote debugging capabilities.

MacStadium

Infrastructure provider offering both dynamic ephemeral runners and static runners with Orka virtualization. Provides Mac hardware rental starting at $199/month for M4 Mac mini with automatic scaling based on CI demand.

References & Further Reading

"The great virtue of a free market system is that it does not care what color people are; it does not care what their religion is; it only cares whether they can produce something you want to buy."
— Milton Friedman
Crafted by Pedro PiñeraView Source