Are Managed GitHub Actions Runners Secure?

Answer

Yes, when the runner is an ephemeral virtual machine rather than a long-lived host. On WarpBuild, each runner runs in its own virtual machine, the virtual machines are created on demand and destroyed after each build, and no machine is reused between jobs.

That single property answers most of what a reviewer asks about a managed runner, because it removes the class of problem where one job reads what an earlier job left on disk. Two more documented facts sit next to it: each runner has its own encrypted storage volume that is created on demand and destroyed after each build, and WarpBuild does not access or store any build secrets, which stay in your source code repository and reach only your runner environment. All three are stated in the WarpBuild runner security documentation.

The table below puts those properties against the two baselines reviewers usually already know.

Sources for the first column: the runner security documentation and trust.warpbuild.com, checked on 2026-08-13. The third column is the shape GitHub's own self-hosted runner security guidance warns about, and it is why container-based runner setups such as ARC need extra work before they can face untrusted code.

Every label in that catalog resolves to a machine under the first column.

Detail

What a reviewer can record from the isolation model

The lifetime of the machine equals the lifetime of the job. Nothing is pooled and nothing is warmed by keeping an earlier job's machine alive, so a reviewer can write three facts into a questionnaire without a follow-up call:

• Isolation unit. One virtual machine per job, with no shared tenancy between builds.
• Storage lifetime. One encrypted volume per runner, created on demand and destroyed when the build ends.
• Secret custody. GitHub holds the secrets. WarpBuild does not access or store them.

The practical consequence of the second point is that anything a job wants to keep has to be written somewhere deliberately, through the cache, an artifact upload, or a snapshot. When caching is enabled, the cache is encrypted and stored in a location that is only accessible to your runner.

The labels a review actually covers

A review covers the runner labels your workflows can name, so the label list is worth attaching to the questionnaire. Each label below gets the same per-job virtual machine and the same encrypted volume, at the size and published rate on the pricing page, checked on 2026-08-13.

The storage column is the volume that gets destroyed with the machine. A reviewer asking "where does the source checkout live" is asking about that column, and the answer is that it lives there for the length of the build and then goes away with the volume.

Public repositories

Managed runners register as self-hosted runners in the Default runner group of your GitHub organization, and GitHub disables self-hosted runners on public repositories by default. Enabling them is one checkbox: open the Default runner group settings for your organization and check Allow public repositories, as described in the public repositories documentation.

The caution behind GitHub's default is real for long-lived runners. A pull request from a fork can carry code that runs on the machine, and on a host that outlives the job that code can leave something behind for the next job. A per-job virtual machine that is destroyed after the build removes that path, which is why the public repositories documentation states that WarpBuild runners provide the same safety as GitHub-hosted runners for this case.

Two GitHub-side settings still carry weight on a public repository. GitHub does not pass repository secrets to a workflow triggered by a pull request from a fork, per the GitHub secrets documentation, and a narrow permissions block limits what the job's GITHUB_TOKEN can do if the workflow is ever tricked into using it.

name: pr-checks
on:
  pull_request:

permissions:
  contents: read

jobs:
  test:
    runs-on: warp-ubuntu-latest-x64-4x
    steps:
      - name: Checkout the pull request head
        uses: actions/checkout@v5
        with:
          persist-credentials: false

      - name: Install dependencies
        run: npm ci

      - name: Test
        run: npm test

persist-credentials: false keeps the checkout action from writing a token into the local git config, so a build script cannot read it back out of .git/config. On a machine that is destroyed after the build the exposure window is one job, and the setting closes it inside that job as well.

Fork pull requests that genuinely need a credential belong in a separate workflow on a separate trigger, gated behind an environment with required reviewers, so the approval is a human decision rather than a property of the runner.

Reaching private services

Jobs that need a private database or an internal API reach it through the Networking addon rather than through an inbound hole in your network. You create a network addon configuration, add network.name=<config-name> to the runs-on label, and the runner joins your Tailscale tailnet using an ephemeral node key when the job starts. When the job finishes, the ephemeral node is removed from the tailnet automatically, which matches the lifetime of the machine itself.

jobs:
  integration:
    runs-on: warp-ubuntu-latest-x64-8x;network.name=production-tailnet
    steps:
      - uses: actions/checkout@v5
      - name: Run integration tests against the private API
        run: ./scripts/integration.sh

The networking documentation covers the Tailscale trust credential and the tag scoping, and the tags a runner may advertise are a subset of the tags you configure, so the blast radius of a compromised job is bounded by the tailnet policy you wrote.

One control plane detail belongs on the same page of a review. The WarpBuild control plane calls GitHub from three static egress IP addresses. If your organization uses a GitHub IP allow list or restricts inbound traffic to a GitHub Enterprise Server instance, those addresses need to be on the allow list, and they are published in the GitHub Enterprise documentation.

Teams whose policy puts the runner instance itself inside their own account run BYOC instead, where the instance, its network, and the storage bucket are resources in your cloud account. The AWS BYOC page covers that setup and the hardening steps that come with it.

Compliance evidence

The report and the supporting security documentation are request-gated: ask for them through trust.warpbuild.com, which is the linked evidence for the attestation and the place a reviewer goes rather than a sales thread.

The security review checklist collects the five questions in the order reviewers ask them.

Related Questions

Are managed runners safe to use on public repositories?

Yes. Each job still runs in its own virtual machine that is created on demand and destroyed after the build, so a pull request from a fork gets a clean machine that nothing else reuses. GitHub also withholds repository secrets from workflows triggered by a fork pull request. Public repositories need one setting change first: check Allow public repositories on the Default runner group in your GitHub organization settings, per the public repositories documentation. The open source pricing answer covers what those runs cost.

Can a runner reach services on our private network?

Yes, through the Networking addon. You create a network addon configuration, add network.name=<config-name> to the runs-on label, and the runner joins your Tailscale tailnet with an ephemeral node key at job start and is removed from the tailnet when the job finishes. Separately, if your organization uses a GitHub IP allow list, allowlist the three static WarpBuild control plane egress IPs. Teams that want the instance inside their own account use BYOC on AWS.

Does WarpBuild access or store our build secrets?

No. WarpBuild does not access or store any build secrets. Secrets are stored in your source code repository and are only accessible to your runner environment, which lives for the length of the build and is then destroyed along with its encrypted storage volume. The source code answer covers the same question for the repository contents.

What does a security review need from a runner vendor?

Five documented answers: how jobs are isolated, how long build storage lives, whether the vendor can read secrets, what compliance attestation exists, and where runner traffic goes. The security review checklist lays out the full sequence.