RunsOn RunsOn
RunsOn RunsOn

Security

No third-party shared runner plane. RunsOn keeps the core GitHub Actions runtime in your own AWS infrastructure.

RunsOn handles security differently from hosted runner SaaS products because the default deployment model keeps the core runtime path in your AWS account.

At a high level:

  • runner VMs are ephemeral and isolated by default
  • caches, logs, queues, and GitHub App credentials stay in your AWS account by default
  • the RunsOn server runs in your AWS account with a limited IAM role
  • the main RunsOn-side data flows are limited to license validation, product telemetry sent to runs-on.com, and normal commercial or support communications

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.
  2. Switch to a third-party SaaS tool like BuildJet or Warpbuild to get cheaper and more powerful self-hosted runners, but at the cost of handing a third party access to code, secrets, and runtime data.
  3. Maintain a pool of long-lived self-hosted runners, which often means patching drift, state leakage between jobs, and a much larger attack surface.

A strong design rule of RunsOn is that it always spawns a new runner for each workflow run. That makes job isolation straightforward and avoids persistent runner state leaking into later workflows.

And since RunsOn and its runners live in your own AWS account, your code and secrets do not need to move into a third-party shared runner control plane.

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

How RunsOn handles security

The most important security property is architectural: RunsOn is not a shared hosted service for your workflow execution.

What stays in your AWS account

By default, the following remain in your environment:

  • runner VMs and workflow execution data
  • S3 cache contents and CloudWatch logs created by the deployed stack
  • SQS queue payloads and workflow-processing state
  • private GitHub App credentials created during setup

This is also why RunsOn’s public Data Processing Addendum is intentionally narrow.

Public base images (AMI)

RunsOn maintains public AMIs for the base images used by the runners, in each region where RunsOn is officially available. These images are built from this repository and are updated regularly, within 48h of an official new release by GitHub.

If you want maximum supply-chain control, you can build your own images from the provided templates or generate entirely custom AMIs.

RunsOn server (AppRunner)

The server is deployed from a Docker image built by RunsOn and published in a public ECR registry: public.ecr.aws/c5h5o9k1/runs-on/runs-on.

The server container runs in your AWS account, using AppRunner and a limited IAM role.

The RunsOn server validates the RunsOn license agsint a runs-on.com API endpoint. That request includes the GitHub organization, AWS region, license key, and app version needed for the license check.

RunsOn agent (EC2 instance)

Since v2, an agent lives on the EC2 instances launched by the server. This improves boot behavior and helps with metadata generation, spot interruption handling, and workflow lifecycle management on the runner.

On job start, the agent also sends limited technical telemetry to a runs-on.com API endpoint, including:

  • the current time
  • org or account identifier
  • app version
  • AWS region
  • platform
  • instance architecture
  • instance type
  • instance lifecycle
  • instance boot timings
  • whether the stack is using private networking
  • whether the stack targets GitHub Enterprise Server
  • enabled integrations
  • networking stack
  • enabled extras
  • pool metadata when applicable

This telemetry is used to understand product usage and improve compatibility, performance, and reliability. It is not in the main workflow execution path, and it does not by default include repository contents, secrets, or runner filesystem contents.

RunsOn-side security controls and vendor roles

RunsOn-side systems only handle limited data flows compared with the core product runtime. For those RunsOn-side flows:

  • HTTPS/TLS is used for the telemetry and license-validation endpoints.
  • Access to support materials is intended to be limited to authorized personnel with a need to know.
  • Controller-side vendors and processor-side subprocessors are disclosed separately so procurement does not need to infer roles from generic security copy.

Current public procurement documents:

Supply-chain and service risks

Some of the main risks and corresponding mitigations are:

  • malicious code injected into the base AMIs: mitigate by auditing the published AMIs or building your own from the provided templates
  • malicious code injected into the server component: mitigate by auditing the source or images available under the relevant license model, or by rebuilding and publishing your own image
  • malicious code injected into the agent component: mitigate by auditing the source or published artifacts and, if needed, rebuilding the component for your own images
  • compromise of the limited runs-on.com services used for telemetry or license validation: these flows are separate from the core runner execution path in your AWS account
  • compromise of the RunsOn server endpoint in your AWS account: the service is internet-facing to receive GitHub webhooks, but it runs behind AppRunner infrastructure and with a limited IAM role

Conclusion

RunsOn’s security model starts with keeping the workload path in your infrastructure and keeping RunsOn-side processing narrow. If anything in this documentation seems unclear or you need a procurement answer tied to a specific data flow, contact ops@runs-on.com.