GitHub Runners: Cloud VS Self-hosted
When setting up a CI/CD pipeline, should you use GitHub Cloud Runners or a self-hosted runner?
I’m working on developing a complete CI/CD pipeline, which means I need a runner to handle automated processes. The big question is: Should I run them locally or use the cloud?
Cloud Runners: A Convenient but Limited Option
Yes, you can use cloud runners, but there are some things to consider before jumping right in.
GitHub’s cloud runners currently offer 2,000 minutes of runtime for free accounts and 3,000 minutes for Pro accounts. That might sound like a lot, and depending on your application, it could be enough. But let’s break it down.
To test if the limits were sufficient, I created a simple Unity project with two buttons that updated a TextMeshPro object. I used the Unity CI/CD scripts from GameCI and ran a WebGL build on a GitHub cloud runner.
Each build took about 14 minutes on average. This means a free account can handle roughly 150 builds per month, while a Pro account allows for around 215 builds.
At first glance, this might seem like enough. But keep in mind that these limits apply to all GitHub Actions across all your repositories—not just builds. If you're running tests, deployments, or other workflows, the minutes can add up quickly.
GameCI is an open-source project with great resources for setting up CI/CD pipelines for Unity.
I checked the logs to see if anything was slowing down my builds, and I found a major issue:
Each time the workflow ran, it had to download, install, and configure the GameCI Unity Build environment from scratch! This is a huge drawback because it significantly increases runtime for every build.
I tried using the GitHub action for caching but it did not work. I think, this is because every time you run an action on a GitHub cloud runner you get a fresh instance of a virtual machine and even if you cache the environment, you still have to download and install it.
Self-Hosted Runners: A Game Changer
To compare, I decided to try self-hosting a GitHub runner on an old laptop. (I’ll be writing a detailed guide on how to set this up soon: [[Setting up a Self-Hosted GitHub Runner]]).
At first, the results were scary: The initial build took 30 minutes! I started doubting whether my hardware was good enough. But then, I ran the build again, and… oh boy!
It took only 2 minutes!
Why Was the Second Build So Much Faster?
Unlike cloud runners, a self-hosted runner keeps its environment between runs. This means:
✅ Dependencies don’t need to be reinstalled every time.
✅ No need to re-download the Unity Build environment each time.
For me, this huge speed boost made self-hosting worth the setup effort.
Summary: Cloud vs. Self-Hosted Runners
| Feature | GitHub Cloud Runner | GitHub Self-Hosted Runner |
|---|---|---|
| Ease of Setup | ✅ Very easy | ❌ Difficult manual setup |
| Cost (Free Tier Limits) | ❌ Limited or paid runtime | ✅ No runtime limits |
| Build Speed | ❌ Slower (fresh VM each time) | ✅ Faster (persistent environment) |
| Control | ❌ Limited | ✅ Full control over environment |
Final Thoughts
If you’re just starting out or running small, infrequent builds, GitHub’s cloud runners are a hassle-free option. However, if you’re dealing with frequent builds, large projects, or long runtimes, then setting up a self-hosted runner can save you time and remove limitations.
For me, the performance improvement was too good to ignore. What about you? Are you using cloud runners, or have you tried self-hosting? Let me know in the comments!
