Skip to content
Using runners

Security and isolation

One job runs on one virtual machine, and that machine is deleted when the job finishes. This page explains what that means in practice.

The life of a job

  1. GitHub sends a workflow_job webhook with action: queued. We verify the webhook signature and record the job.
  2. We ask GitHub, through the app installation, for a just-in-time runner configuration. It can register exactly one runner, which accepts exactly one job and then deregisters.
  3. A new Firecracker microVM boots from a read-only base image, with a fresh copy-on-write disk, its own kernel and its own network namespace.
  4. The GitHub Actions runner inside the VM connects to GitHub and receives the job. Secrets, the checkout token and the job's steps come straight from GitHub to the VM.
  5. When the job completes, is cancelled, or times out, the VM is stopped and its disk is deleted.

What isolation covers

BoundaryHow
Between jobsA separate microVM per job with its own kernel. Never reused, including between jobs of the same repository.
DiskCopy-on-write layer on top of a read-only image, deleted with the VM. Nothing written by a job is visible to a later job.
NetworkPer-VM network namespace. VMs cannot reach each other or the host's management network. Outbound internet is allowed; inbound connections are not.
CredentialsThe runner registration is single-use and scoped to one job. Our control plane never sees repository secrets.

What we store

Job metadata from GitHub's webhooks: repository name, workflow and job name, label, status, conclusion, timestamps and the link to the run. We use it for billing and for the dashboard. We do not store logs, artifacts, source code or secrets; logs stay on GitHub.

GitHub App permissions

The app requests only what GitHub requires to register runners and read job status. It cannot read repository contents. You choose which repositories it can see when you install it, and you can change that in GitHub at any time.

Public repositories and forks

GitHub warns against self-hosted runners on public repositories because a fork's pull request could leave something behind on a long-lived machine. Single-use VMs remove that persistence. A fork's workflow still runs with whatever permissions the workflow grants, so keep GitHub's setting that requires approval for workflows from outside contributors.

Reporting a vulnerability

Email security@runloft.dev. Please include steps to reproduce; we reply to every report.