macOS environments are something you don't want to be dealing with for automation. I'd outsource managing that infra to someone many times. I remember during my time at Shopify when we had to maintain a fleet of Mac minis, which we provisioned using Ansible, to among other things, install the virtualization technology, Anka, and then plug them as runners into Buildkite. It was a pain to work with. We used MacStadium at the time, and I remember thinking, having solved running those environments, which Apple doesn't design for making things easy, I don't understand why they don't leverage the scale at which they operate to provide a developer-friendly interface that can match the elastic needs of a consumer, whether the consumer is just a company that needs CI, or a company that builds solutions that require macOS environments. This is something only companies that operate at scale can offer, and MacStadium was one of them.

For many many years, the model was, you need a Mac mini? You pay for it and keep it for at least 24 hours. If you need two, then get the second one, and same story, keep it for 24 hours. As I mentioned, this is a legal requirement by Apple. But it's annoying, especially if you can't predict the demand of environments that you are going to have. I don't know if tomorrow I'll need 1 or 2, or 20, that depends on many things that are out of my control. I remember chatting with a Tuist user who said that their CI provider required them to estimate how much workload they'd have. My immediate question was, how do you calculate that? The answer was, well we give them ballpark numbers. Some CI companies could eventually afford a more elastic model where you'd pay per usage, in fact GitHub Actions did it, but very understandably pricey. Still, there was a bit of light that we'd see a similar model outside of the CI spaces for companies like Tuist, where we need a platform upon which we can build a solution with elastic demand. The first feature we started to think about was Tuist QA. We don't want to build a system that predicts and demands for more or fewer Mac Minis ahead of time. We wanted a system where we could ask for a Mac Mini, use it for as long as we needed, then shut it down, and then pay for it. How that Mac Mini is then reused, I don't care, it's your business, not mine. And not only that, but give me an API that I can use. I call your API, I get a Mac mini asynchronously with SSH access to it. I'm done, and then I call another API for you to take it back. And in case shit hits the fan, just allow me to set a timeout to shut it down automatically. Why doesn't such service exist? It turns out it exists, and it's Namespace.

When I came across it, Namespace was too good to be true. Exactly the developer-friendly API that we were looking for. A company that operates at the scale that we needed for that elastic demand, and an extremely talented team that cared about the product and how their customers would use the product. We got in touch with Hugo & Eva, and they set everything up for us to start building Tuist QA on top of it, and it felt such a joy to use. Few companies go the extra mile of nailing developer experience, and I think Namespace has gone that extra mile. It reminds me of companies like Fly.io, who made scaling services into new regions as easy as running a command like fly scale count --reg mad 2. I guess you understood what the command does without me telling you about it. I don't care about what it takes to proxy the requests to that new region, but I trust you'll do a good job. The same happened here, I don't really care about the limitations. I just care about getting and returning a Mac. MacStadium could have built something like this, but they missed the train. You can tell the team at Namespace has extreme attention to great product and it shows.

So as you might have guessed, our Tuist QA builds on it, so will other features, like signing on the fly, which we'll build down the road. Building on the service and getting support from their team has been exceptional. They recently told us they built a solution where they could bind the lifecycle of a machine to the lifecycle of a containerized runtime process, and it felt like they had been reading our mind. It's exciting to see DX innovation in a space that seemed to have succumbed to just CI as the only consumer of those environments. There are many companies like Tuist that will have a need for these environments for more than just CI, and this is going to be particularly relevant in the world of agents, where some operations might need to run remotely in sandboxed environments. Namespace is well positioned to take a big chunk of that market, and I'd personally be excited in that case because they really deserve it.

If you are considering moving your CI back to GitHub Actions, or GitLab CI, and just need runners that are better and more fairly priced than the ones that you get from GitHub, I'd recommend giving them a shot and shooting them an email. They are one of the nicest teams to work with and they'll work with you on providing you the best value.