Alternatives to the macOS Runner for GitHub Actions

There are a few alternatives to using the in-built GitHub macOS runner for your actions workflows. All of them still connect to GitHub in order to run the workflows, but it all comes down to where the hardware is hosted.

I'm not going to go through the setup of a self-hosted runner in this article but will in the next as I go through setting up Cilicon.

Alternative Options

The two categories that alternative runners fall into are cloud-based and local-based solutions. Of course for most, if not all of the local-based solutions could run on cloud-based systems.

This is something to keep in mind, but you'd need to check the cost of all these since the upward scale can increase the price very quickly.

Cloud-Based Solutions

One alternative to using the in-built GitHub macOS runner is to use a cloud-based solution. Some popular options include:

Bitrise

Bitrise is a fairly popular option when it comes to continuous integration (CI) and continuous delivery (CD). You'll often hear it referenced by Swift developers as their go to system since it does handle a lot of the guess work for you.

One of the bigger advantages to using Bitrise is the hardware they supply. You are on the M1 Mac Mini hardware which means the OS version will be up to date and allows access to the latest Xcode, and Swift versions.

This is leaps and bounds ahead of Github since you're no longer tied to old versions or incompatibilities. The hardware itself is also probably better than a lot of personal machines too:

M1 Elite XL
6 credits/min
8 CPU @3.2GHz 12 GB RAM
Running on Apple Silicon, M1 Mac Minis

It is important to note though, you are using a 6x multiplier when running your projects, at a 300 minutes entry package. You also have access to the Standard system, at a 2x multiplier - it'll probably just run for longer.

MacStadium

MacStadium is another option to run your system on. Essentially you are renting a piece of Mac hardware to run your software and testing on.

Again it runs higher processing than Github, but is fairly steep at $152/mo. for the machine. However, if you're looking into MacStadium as an option, probably think of other tasks you can run on it other than just Github actions.

This solution is more if you don't have access to a Mac and want to do more than Github actions. Otherwise you may as well pay for the extra Github minutes outside of your 2000 base tier inclusions.

Weirdly though, apparently Github use MacStadium for their macOS runners, which makes the operating system versioning even more confusing.

CircleCI

I've only heard of CircleCI and never used it - so this is all from base level research.

Again it is a system with credits or runtime minutes, and there are different levels of credit multipliers depending on your package.

For the entry free tier, you are hit with a 50x multiplier per minute, but you do get 30,000 per month. That's still 600 minutes in total to play with. Compared to Github you only get 400 minutes in total and Bitrise you only get 50.

I know it isn't all about the total minutes, and these are the free tiers, but I'd feel like you would want some level of bang-for-buck before paying.

Local-Based Solutions

The other option to all of the subscription services is to BYOD - bring your own device. There are some limitations or things to know if doing this compared to cloud particularly maintenance.

There are five options which I think are viable, but I am sure there are many more. They all are similar in one way or another, really only differentiating on what the "host" is.

The ones I think worth looking into are:

• your physical local macOS machine
• VirtualBox
• VMWare Fusion / ESXi
• Jenkins
• Cilicon

The reason I like these local-based solutions is that you are already on these devices building your project to begin with. Hosting the action runner there would be a single step in your pipeline.

It's not even that difficult to add it to your project too, for example:

#!/bin/bash

# -- open a terminal window
open -a Terminal .

# -- start the runner
~/actions-runner/run.sh

# -- commit all changes to git
git add .
git commit -m "Committing all changes"

# -- push changes to remote
git push origin main

What's great about this is you own the hardware so you control the versions of operating system, and installed dependancies. As a result of the maintenance you don't get charged for running the action, no matter how long it is.

Cost and Performance

I've already written about the cost and performance when using cloud-based solutions but what about local-based? There are some things to take note of if using a self-hosted runner:

One of the biggest issues is that this is now required to run 24/7 on your machine - or at leash be available when the action is triggered.

For some, this might be okay - others not. If you're an indie developer you're probably the only one or part of a small team that will need to run the action so your Mac computer will already be on.

In fact, if you have a small team you could all add in your own self-hosted runners and activate it when you are working. This system works well, because if you have all three runners active then it will round-robin to one and use that as the resource. But only run on active runners, not offline ones.

However, if you have a repository that uses Swift and want to run it on a CRON schedule, then leaving the Terminal open indefinitely could be annoying if not resource hungry.

It also is no longer resistant to power failure, accidental terminations, or network inaccessibility. Which is one leg up for running these actions on Github or cloud-based resources.

However, many users of Github actions most likely have 24/7 servers or systems running. They probably also rely on network connectivity always being available.

There's also a learning curve if using something like Jenkins for your actions, and it also takes you out of Github actions completely. It's similar in the use case, but as mentioned in the other articles the ideal solution would mean less branching of frameworks.

Virtualisation

I'm not an expert on virtualisation, but I do use VMWare ESXi daily at work, and have started to test out XCP-ng, so I do have a good grasp on them. VirtualBox sits very close in the scope of the use case to run macOS outside of the host, so assume it applies here too.

I've set up a VM on an ESXi server on my Intel NUC. I know this is more Hackintosh than Macintosh running it here, but it was more to set it up, configure it locally, then migrate it to a location which was more viable.

When you finish setting up the self-hosted runner you do start to think, "isn't this no different to running it on my local mac?"

The only benefit I was gaining was that it was off-device meaning if I only worried about that machine being connected and powered then it would be always online.

But I've had issues before running VMs that aren't headless being major resource hogs. There's always some resource draining the system even if it's not being accessed. This is why Linux machines really are the backbone to a lot of the set-and-forget infrastructure systems.

You also do get the portability factor with virtualisation, allowing you to make clones and move them where you need, when you need them. But there is also a financial cost to running these systems - mainly licensing, as well as additional compatible hardware.

Cilicon

The one local-based, self-hosted runner solution I haven't written about is Cilicon.

I didn't know about Cilicon until I saw this tweet from Simon Støvring:

Anyone have experience hosting ephemeral virtual machines running macOS that will act as runners for Github Actions? I'm looking for software to facilitate this. Currently looking at Cilicon but I would like to explore my options. https://t.co/pdysUSqYCE

— Simon B. Støvring (`@simonbs`) January 10, 2023

Cilicon sits in a nice medium between virtualisation - like VMWare Fusion/ESXi or VirtualBox - and running the Github action in your own Terminal on localhost.

It does in every aspect represent a VM, but it seems to be build around Github actions - or at least with this in mind.

The way it is designed means you can set it up in Editor Mode where you can formulate your startup script. Once everything is configured, you disable editing and the VM will boot into your script.

It then listens for the Github actions as the self-hosted runner, with some additional features like tear-downs after n amount of runs.

I've actually come to really like Cilicon, and am actively testing its viability for my needs.

Conclusion

Overall, there are many alternatives to using the in-built Github actions runners but you need to check what the cost will be compared to using some of the other solutions.

Particularly if you need to access additional hardware to run on you may not see the financial benefits of it compare to paying for a few more minutes per month.

Alternatively, if you have old hardware sitting doing nothing, you can give it a new purpose in life by designating it as the core action runner.

I'd recommend a solution incorporating both, but understand not everyone can achieve that. But if you can, setting the self-hosted runner as primary and cloud-based as a backup you'll get the cost savings as well as the connectivity security.