Introducing Fireactions: Self-host your GitHub runners without a sweat

Scaling and boosting GitHub Actions runners is a must for those with high Continuous Integration / Continuous Deployment (CI/CD) workloads. Self-hosting the runners is a great solution, but it’s complex and time-consuming. This inspired us to create Fireactions, an open-source orchestrator for GitHub runners.

Fireactions allows you to Bring Your Own Metal (BYOM) and self-host GitHub runners in short-lived, fast, and secure Firecracker-based virtual machines. It’s ideal for organizations, freelancers, and hobbyists looking to reduce workflow queue times, minimize costs, and decrease maintenance overhead.

Find detailed instructions on how to install, configure, and use the application at Fireactions.io or visit the Fireactions repository for the code, quickstart guide, and contribution opportunities.

The problems we needed to solve

Like many software companies, we utilize a CI/CD pipeline to streamline code integration, testing, and deployment.

We heavily rely on GitHub Actions to manage the process. However, with the rapid expansion of microservices and the growing number of repositories, our increased CI/CD workload created stability and scalability challenges.

The immediate pain point was the lengthy delays due to queued jobs, slowing down our entire development and release process.

With plenty of bare metal on hand, we decided to run self-hosted GitHub runners on our own infrastructure. This way, we could optimize build times, enhance efficiency, and ensure a more reliable and scalable CI/CD pipeline as we continue to grow.

There are several options to do this, such as Actions Runner Controller, but it requires Kubernetes and privileged containers, which add complexity, increase maintenance overhead, and pose potential security risks.

We needed a more flexible solution. We wanted the same level of control, reliability, and security as with GitHub-hosted runners but without their limitations, such as long startup times and limited resources.

What Fireactions is and how it works

We chose Firecracker, an open-source virtual machine monitor (VMM), to deploy workloads in micro virtual machines (microVMs).

MicroVMs are ideal for running untrusted workloads, such as CI/CD jobs. Unlike containers that share the host operating system, microVMs run their own lightweight kernel. This provides stronger isolation and security while maintaining speed and resource efficiency.

However, it takes time and effort to set up and maintain the GitHub runners. This is where Fireactions steps in. It’s a completely free, open-source self-hosted CI/CD solution that automates GitHub runners.

Here’s how it works:

First, Fireactions loads the configuration file to determine the setup, and starts pools of runners. It continuously checks to ensure there are enough runners available.

For a new runner, Fireactions requests a token from GitHub, then quickly creates an isolated microVM using Firecracker. Once the job is complete, Fireactions destroys the microVM. Just like with GitHub-hosted runners, no state is preserved between jobs.

Fireactions automatically scales the number of runners based on incoming workflow events. You can define job labels and customize virtual machine resources to fit your needs.

You can run Fireactions on any regular bare metal server or a virtual machine that supports nested virtualization – virtual machines running within other virtual machines.

Our results

Fireactions has paid off in spades, and all the teams working with CI/CD workflows have felt the impact.

To put things in perspective, we recorded 835,186 minutes of build time on Fireactions over the past month alone. This figure includes all CI/CD workflows, from simple tests to complex deployment pipelines.

Our initial and critical target was reducing job queue times by at least 90%. Instead, we’ve reduced the queues to zero.

Depending on the configuration of the bare metal server and its resources, Fireactions builds can take up to 20x less time than GitHub-hosted runners, particularly for resource-intensive tasks.

The average GitHub runner startup time on Fireactions is 20 seconds. Meanwhile, creating and booting runners on traditional virtual machines typically takes a minute or more.

Giving back to the community

At Hostinger, we use many open-source tools and want to give back to the community. Therefore, we developed Fireactions as an open source from the very beginning.

It took approximately three months for our core development team of two engineers to develop a robust solution while managing other responsibilities.

We moved all GitHub workflows to Fireactions and fixed issues in almost a year. This includes three major refactorings, enhancing performance, scalability, and maintainability based on the feedback and challenges encountered during the initial deployment and scaling phases.

We continue enhancing Fireactions based on user feedback. We also encourage and value all types of contributions to the project.

Fireactions is our second open-source project launched recently. We launched AI assistant Kodee in September, and shared an open-source Kodee demo repository with instructions how you can set up a similar system.