Do GitHub Actions Runners Store My Source Code?

Answer

No. A WarpBuild GitHub Actions runner holds your source code only while the job runs, because each runner gets its own virtual machine and its own encrypted storage volume, both created on demand and destroyed after the build. Everything that outlives the job is a named surface with its own retention setting: cache entries a step saved, objects in a bucket inside your own cloud account on BYOC, and snapshot images if you turned snapshot runners on.

That distinction is the one a security reviewer is actually asking about. The question sounds like it is about the runner, and the answer lives in four separate storage surfaces with four different lifetimes and four different delete buttons.

Two boundaries hold across all four rows. GitHub keeps the repository, the workflow definitions, and the secrets, since a runner is a machine that clones from GitHub and streams results back to it. WarpBuild does not access or store any build secrets; they stay in your source code repository and reach only the runner environment for the duration of the job. Both facts are documented in the WarpBuild runner security documentation, which is the page to hand a reviewer first.

The catalog scope is worth stating alongside the answer, because a reviewer will ask which runners the model covers. Every label in that catalog resolves to a per-job virtual machine under row one of the table.

Detail

The job disk and why its lifetime is the whole answer

Each runner runs in its own virtual machine. The virtual machines are created on demand and destroyed after each build, and they are never handed to a second job. Each runner also gets its own encrypted storage volume, created and destroyed on the same schedule.

Your source code lands on that volume the moment actions/checkout runs, along with whatever the build produces afterward. When the job ends, the volume goes with the machine. There is no warm pool holding a working tree from an earlier run, and no long-lived host that ran your build this morning and someone else's build this afternoon.

For a vendor questionnaire, that turns into three recorded facts:

• Isolation unit. One virtual machine per job, with no shared tenancy between builds.
• Storage lifetime. One encrypted volume per job, created on demand and destroyed after each build.
• Encryption at rest. The per-runner volume is encrypted, and when caching is enabled the cache is encrypted and stored where only your runner can reach it.

The attestation behind those statements is SOC 2 Type 2, with three Trust Services Criteria: Security, Availability, and Confidentiality. Request the report and the supporting security documentation at trust.warpbuild.com. The security review checklist collects the five questions reviewers ask in the order they ask them.

What persists on hosted runners, and how to bound it

Cache entries are the surface teams forget. A cache step writes the paths you name into WarpBuild cache storage, and those bytes survive the job by design, because that is the entire point of a cache.

Three properties bound the exposure:

• Scope. A cache entry is scoped to the key, the cache version, and the branch. A cache saved on warp-macos-latest-arm64-6x cannot be restored on warp-ubuntu-latest-x64-4x, because the version hash differs across compression tool and cached paths.
• Expiry. Cache is set to expire after 7 days of last use, per the WarpBuild caching documentation.
• Manual deletion. An entry can be deleted at any time, either from the console or with the delete-cache input on the cache action.

The practical control is choosing what goes into path. Caching package manager download directories keeps registry tarballs in cache storage and keeps your working tree out of it. Caching the repository directory itself does the opposite.

name: build
on:
  pull_request:

jobs:
  build:
    runs-on: warp-ubuntu-latest-x64-4x
    steps:
      - uses: actions/checkout@v5

      - name: Restore dependency cache
        id: deps
        uses: WarpBuilds/cache@v1
        with:
          path: |
            ~/.npm
            ~/.cargo/registry
          key: deps-${{ runner.os }}-${{ hashFiles('**/package-lock.json', '**/Cargo.lock') }}
          restore-keys: |
            deps-${{ runner.os }}-

      - name: Install dependencies
        if: steps.deps.outputs.cache-hit != 'true'
        run: npm ci

      - name: Build
        run: npm run build

      - name: Test
        run: npm test

The two paths named there are download caches owned by the package managers. No file from the working tree enters cache storage, so the only bytes that outlive the job are third-party archives your build would have downloaded again anyway.

When an entry does need to go, a maintenance workflow removes it by key:

name: purge-cache
on:
  workflow_dispatch:
    inputs:
      cache_key:
        description: Exact cache key to delete
        required: true

jobs:
  purge:
    runs-on: warp-ubuntu-latest-x64-2x
    steps:
      - name: Delete the cache entry
        uses: WarpBuilds/cache@v1
        with:
          path: |
            ~/.npm
            ~/.cargo/registry
          key: ${{ inputs.cache_key }}
          delete-cache: true

What persists on BYOC, and the lifecycle policy to set

BYOC moves every persisted byte into your account. A WarpBuild Stack creates one object storage bucket in the region you selected, and that bucket is used for artifact cache, container image layer caches, and telemetry. The AWS BYOC configuration documentation publishes the exact prefixes, which is what an auditor wants when writing a bucket policy:

• Cache: <bucket_name>/<org_id>/artifact_cache/<vcs_org>/<vcs_repo>/<vcs_ref>/<version>/<key>
• Telemetry: <bucket_name>/runner/logs/all/<runner_id>.<log_file_name>

Those objects sit under your own IAM, your own encryption settings, your own access logging, and your own bill. They also sit there until you remove them, so the retention decision is yours to make explicitly. WarpBuild documents the recommendation directly: set an S3 lifecycle policy for the cache and telemetry data according to your organization's policy, and 7 days of retention is recommended. That figure lines up with the 7 day cache expiry on hosted runners, so a team running both placements can hold one retention number across the estate.

Two more BYOC facts belong in the same review note. The bucket region and the stack region are fixed at creation and cannot be changed afterward. US and EU are the regions WarpBuild names publicly for its own infrastructure, and the EU data residency page covers what a written residency clause needs. The AWS BYOC page walks the account connection and the stack setup.

What retention costs, at published rates

Retention is a cost decision as well as a policy decision, and the arithmetic is short. Hosted cache storage bills at $0.20 per GB-month and every cache write, restore, or list operation bills at $0.0001, both from the pricing page, checked on 2026-08-13.

Take a monorepo running 40 workflow runs per weekday across 22 weekdays, which is 880 runs per month. Caching the working tree alongside the download directories means six cache operations per run; caching the download directories alone means four.

The difference is $5.18 per month on this workload, which is small money and a large reduction in what sits outside the job boundary for 7 days. Substitute your own footprint: the storage line scales linearly with gigabytes held, and the operations line scales with runs multiplied by cache steps.

On BYOC, both of those line items are included, and the storage charge you pay is your cloud provider's own bucket pricing under the lifecycle policy you set. Pricing is purely usage based on either placement.

The one surface that persists on purpose

Snapshot runners are the deliberate exception, and describing them as ephemeral would be wrong. A snapshot captures the whole runner disk at the instant the save action runs, and the resulting image is deleted after 15 days rather than at the end of the job. Whatever sat on disk at that moment, including the working tree and any credential a login step wrote, is inside the image.

Two mitigations belong in every workflow that saves a snapshot. Delete credential paths before the save step, and run git clean -ffdx so untracked and ignored files leave the working tree. On public repositories the alias is readable by anyone who can open your workflow file, so cloud credentials, registry tokens, and signing keys have no place in a snapshot at all.

Snapshot storage bills at $0.025 per snapshot-hour and each restore at $0.04 per job, from the pricing page, checked on 2026-08-13. A single alias held for a 720 hour month is $18.00, so the count of live aliases is worth tracking as both a cost line and a retention line.

Related Questions

Does WarpBuild keep a copy of my source code after a job finishes?

No. Each runner runs in its own virtual machine with its own encrypted storage volume, both created on demand and destroyed after each build. The checkout, the dependency tree, and the build output go away with that volume, and WarpBuild does not access or store any build secrets. The security review checklist lists the documentation page behind each of those statements, and are GitHub Actions runners secure covers the isolation model in more depth.

What about snapshot runners? Do those keep my checkout?

Yes, by design. A snapshot is a saved image of the entire runner disk at the moment the save action ran, so the working tree and anything else on disk is in that image, and snapshots are deleted after 15 days rather than at the end of the job. Remove credentials and run git clean -ffdx before the save step. The WarpBuild runner security documentation covers the per-job model that snapshots deliberately depart from.

On BYOC, where do the persisted bytes land?

In an object storage bucket inside your own cloud account, in the region you pinned when you created the stack. The same bucket holds the artifact cache, container image layer caches, and runner telemetry logs, and the AWS BYOC configuration documentation recommends a 7 day lifecycle policy on it. The AWS BYOC page covers the account connection and the stack region choice.

Can I keep every persisted byte in one region?

US and EU are the regions WarpBuild names publicly for hosted runners, and enterprise customers can pin hosted runners to one of them. On BYOC the region is your stack region, fixed at stack creation, so the placement decision happens before any runner exists. The EU data residency page covers the hosted side, and the pricing page carries the per-minute rate for every runner label.