Skip to content


RunsOn handles security very differently from competitors or alternative ways of self-hosting runners:

  • only ephemeral, fully-isolated VMs, so that nothing can leak from workflow to workflow.
  • application, code, secrets, and runners stay in your AWS account.
  • special care to only issue the most restrictive set of IAM permissions to the RunsOn application, and runners.
  • regularly updated application (part of why we ask for a subscription).

The problem with self-hosted runners

People looking for cheaper or faster runners often choose one of the following routes:

  1. keep using GitHub official runners. Pay premium price, and have limited access to more powerful runners. Perfect until you start hitting 10min+ workflow times and your developers suffer.

  2. switch to a third-party SaaS tool like BuildJet or Warpbuild to get cheaper and more powerful self-hosted runners. It’s only 2x cheaper though, and might be slower for some workloads that require fast bandwidth. On top of that you are relinquishing access to some of your most precious assets:

    • your source code ;
    • github action secrets, which often include privileged access to artefact repositories, cloud providers, or even other github repositories.
  3. maintain a pool of self-hosted runners: problem is that those are often permanent and require constant patching, as well as introducing huge attack 🔗 vectors 🔗, especially on public repositories.

A strong design rule of RunsOn is that it always spawns a new runner for each workflow run (what is called “ephemeral runners”), so that you can be certain that nothing can leak into subsequent workflow runs.

And since RunsOn and its runners all live in your own AWS account, your code and secrets never leave your infrastructure.

SSH access to the runners can also be restricted to a specific CIDR block, or simply disabled.