GitHub Actions runners

GitHub Actions are not always the best fit. Builds are a bit slow, costs are high, when compared. Managed runner providers and self-hosted runner platforms fill that gap. They usually offer a GitHub-compatible runner, better hardware choices and more flexible/affordable billing. In many cases, moving over is a small workflow change instead of a full CI migration.

Most commercial providers listed here behave as drop-in replacement for GitHub-hosted runners. Others focus on running runners inside your own cloud account or data center. The second model can be attractive when data locality, network access, or custom hardware matters more than convenience. A fully managed service is easier to adopt, while a bring-your-own-cloud setup usually gives you more control and more responsibility.

# Relation to fortrabbit

For most use cases, no dedicated CI service is required for deployment pipelines with fortrabbit. fortrabbit has a deployment service for Git-based workflows. Connect your GitHub repos and let fortrabbit handle deployments after git push. See the deployment intro.

In certain edge cases, you may require more control or specific tooling that is not available with fortrabbit. This is where you can consider using GitHub Actions directly, or a third party service (what this is about).

There is no platform-level integration required on the fortrabbit side to connect a GitHub Runner. These services run your CI jobs on external infrastructure. The final deployment step still happens over SSH, for example with rsync or another SSH-based workflow. Integrate the service with a deploy key - a special SSH key to connect external services.

# Self-hosted DIY solutions

The most affordable solution can be to just use deploy server (think VPS) to run your actions. This can

• github.com/jonico/awesome-runners - glue software overview