Zero Egress Costs for GitHub Actions Runners

Zero egress for GitHub Actions runners means your cloud provider stops charging you for the gigabytes your workflow jobs pull out of it. On the WarpBuild enterprise tier, egress costs from your cloud drop to zero when runners pull large artifacts from ECR, S3, and similar stores during deployments, and that applies on BYOC runners and on WarpBuild-hosted runners.

This page leads with the arithmetic. Every number below comes from a published list price with a link and a checked-on date, so you can swap in your own artifact sizes and deploy counts and get a figure your finance team can check.

Overview

Deploy jobs are the heavy readers in a GitHub Actions pipeline. A release job pulls a container image from ECR, pulls a signed release archive or a set of migration bundles from S3, and hands them to a cluster or a fleet. Machine learning pipelines pull model weights. Mobile and desktop pipelines pull signing bundles and prebuilt frameworks. Integration suites pull database fixtures. All of that traffic is read out of stores you own, on a schedule set by how often your team merges.

A single deploy job that pulls a 2.5 GB image and 1.5 GB of release artifacts moves 4 GB. That looks small until you multiply it by the number of services and the number of merges. Ten services deploying four times a day is 40 deploy jobs, which is 160 GB a day of reads out of ECR and S3. Your cloud provider bills that volume at its published data transfer rates.

Teams usually find this line the same way: someone opens the cloud bill during a cost review, filters by usage type, and finds a data transfer number that nobody owns. The runner-minutes line is easy to attribute because it sits on the GitHub Actions bill. The transfer line sits on the cloud bill, mixed in with production traffic, and it grows every time a service image gets bigger or a team adds a deploy stage.

On the enterprise tier, runners pull large images and artifacts from ECR, S3, and similar stores with zero egress cost to you. Zero egress applies whether your runners live in your cloud or ours. Deploy-heavy workflows that pull gigabytes from ECR stop generating egress charges on the WarpBuild enterprise tier.

Two boundaries are worth stating plainly before the model.

The first boundary is the tier. This outcome is an enterprise-tier property. Self-serve accounts on WarpBuild cloud runners get the per-minute rates on the WarpBuild pricing page, and the transfer charges from their own cloud stay on their own cloud bill.

The second boundary is macOS. The region-specific infrastructure callout in the WarpBuild cloud runners documentation states that it is not applicable to macOS instances. Linux x64, Linux ARM64, and Windows jobs are the workloads this covers, and those are the platforms that run the container-heavy deploy work anyway.

WarpBuild publishes the outcome and its scope here. The mechanism is not documented publicly, so this page describes what you stop paying rather than how the result is produced. For the general breakdown of where these charges come from in a GitHub Actions pipeline, read where GitHub Actions egress charges come from.

Cost Model

The model below is built entirely from public list prices. State your own assumptions in the same shape and the arithmetic transfers directly.

Assumptions:

• Artifact volume pulled per deploy job: 2.5 GB container image from ECR plus 1.5 GB of release artifacts from S3, so 4 GB per deploy on the medium profile.
• Deploy frequency: merge-to-deploy, counted per service, on 22 business days per month.
• Per-GB rate: AWS lists data transfer out to the internet from US regions at $0.09 per GB for the first tier of monthly volume, with 100 GB per month free aggregated across services and regions. Source: AWS EC2 On-Demand pricing, data transfer section, checked on 2026-08-13.
• The 100 GB monthly free allowance is applied once per month per account. If other workloads in the account already consume it, the billable figure below is an underestimate.
• Volume above the first tier steps down through AWS's published tiers, and rates differ by region. Confirm the tier and the region rate your own account lands in before quoting these numbers internally.
• Google Cloud and Azure publish their own per-GB transfer rates on their pricing pages. Substitute the rate for the provider and region you run in.

Working the medium profile step by step: 40 deploy jobs a day across 22 business days is 880 deploy jobs a month. At 4 GB per job that is 3,520 GB. Subtracting the 100 GB monthly free allowance leaves 3,420 billable GB. At $0.09 per GB that is $307.80 a month and $3,693.60 a year, for one pipeline pattern in one account.

Now put the runner minutes next to it, so the two lines are visible together. Assume the same pipeline runs a 12 minute build job on an 8 vCPU runner and a 6 minute deploy job on a 4 vCPU runner.

Rates come from the cloud runners documentation and the WarpBuild pricing page. For a same-shape anchor against the hosted baseline, warp-ubuntu-latest-x64-8x (8 vCPU, 32 GB) costs $0.016 per minute against $0.022 per minute for the 8-core Linux larger runner (8 vCPU, 32 GB): 27 percent lower list price. GitHub list price checked on 2026-08-13 against the Actions minute multipliers reference.

The runner-minutes arithmetic for the medium profile:

• Build job: 12 minutes on warp-ubuntu-latest-x64-8x at $0.016 per minute is $0.192.
• Deploy job: 6 minutes on warp-ubuntu-latest-x64-4x at $0.008 per minute is $0.048.
• Per merge: $0.24. Across 880 merges a month: $211.20.

Put the two lines side by side and the shape of the problem is clear. On the medium profile the transfer line is $307.80 a month against $211.20 a month of WarpBuild runner minutes. The charge that nobody owns is larger than the charge everybody reviews.

For teams running BYOC, the runner-minutes line changes shape again. BYOC runners cost $0.002 per minute in WarpBuild fees on Linux and on Windows, with the compute billed by your own cloud account, and add-ons are included at no extra charge. The same 18 minutes of pipeline work is $0.036 in WarpBuild fees per merge, or $31.68 a month across 880 merges, plus whatever your own instances cost.

Two things this model deliberately leaves out. It excludes cache storage and cache operations, which are billed separately on the WarpBuild pricing page. It also excludes the transfer your production services generate, since only the GitHub Actions share of the transfer line is in scope here.

If the transfer line is the second item on your list rather than the first, the runner-minutes and storage levers are covered in reduce GitHub Actions costs across runners and storage.

What Changes on Enterprise

On the enterprise tier, egress costs from your cloud drop to zero when runners pull large artifacts from ECR, S3, and similar stores during deployments. This applies on BYOC and on WarpBuild-hosted runners. On the medium profile above, that is the $307.80 monthly transfer line going away while the runner-minutes line stays exactly where it was.

The exclusion stated in the documentation stands: this does not apply to macOS instances.

Almost nothing else about the account changes, which is the point.

Pricing structure stays the same. Pricing is purely usage based. There is no base subscription fee, no platform fee, and no seat fee. Signup includes $10 free credits, and enterprise accounts start from the same self-serve path.

The runner labels and per-minute rates stay the same as the table above.

Deployment shape stays your choice. BYOC runs on AWS, GCP, and Azure. Terraform support exists for BYOC on AWS, so enterprise fleets can be defined in the same repositories as the rest of your infrastructure.

Access and support stay negotiable in the usual places. SSO is available for a flat $250 per month, whatever the user count, and the fee is listed on the WarpBuild pricing page.

Teams that qualify on the enterprise tier usually have a second requirement in the same review, which is where the data stays. That is a separate page: US data residency for GitHub Actions runners.

Two calls to action apply to this page, and they are different paths.

If you want the runners today, sign up at app.warpbuild.com and start with $10 free credits. Change the runner label in a workflow and the rest of your GitHub Actions setup keeps working.

If you want the enterprise-tier outcome on this page, take the qualification path. Bring three months of data transfer line items from your cloud bill and the deploy-job counts from your busiest repositories to a qualification call with the WarpBuild team, or write to [email protected]. The conversation is short when you arrive with the numbers, because the model above is the same model used on the call.

Configuration

Nothing in the workflow file is special. The labels below are the standard WarpBuild runner labels, and they are the labels a qualified enterprise account keeps using.

A build-and-deploy workflow of the shape the cost model describes:

name: deploy
on:
  push:
    branches: [main]

jobs:
  build-image:
    runs-on: warp-ubuntu-latest-x64-8x
    steps:
      - uses: actions/checkout@v4
      - uses: aws-actions/configure-aws-credentials@v4
        with:
          role-to-assume: arn:aws:iam::123456789012:role/github-actions-build
          aws-region: us-east-1
      - uses: aws-actions/amazon-ecr-login@v2
        id: ecr
      - name: Build and push the service image
        env:
          REGISTRY: ${{ steps.ecr.outputs.registry }}
        run: |
          docker build -t "$REGISTRY/checkout-api:$GITHUB_SHA" .
          docker push "$REGISTRY/checkout-api:$GITHUB_SHA"

  deploy:
    needs: build-image
    runs-on: warp-ubuntu-latest-x64-4x
    steps:
      - uses: actions/checkout@v4
      - uses: aws-actions/configure-aws-credentials@v4
        with:
          role-to-assume: arn:aws:iam::123456789012:role/github-actions-deploy
          aws-region: us-east-1
      - uses: aws-actions/amazon-ecr-login@v2
        id: ecr
      - name: Pull the release image
        env:
          REGISTRY: ${{ steps.ecr.outputs.registry }}
        run: docker pull "$REGISTRY/checkout-api:$GITHUB_SHA"
      - name: Pull release artifacts from S3
        run: aws s3 sync "s3://acme-releases/checkout-api/$GITHUB_SHA" ./release
      - name: Roll out
        run: ./release/rollout.sh

The deploy job in that file is the one moving 4 GB per run. The two pulls, the ECR image and the S3 sync, are the volume the cost model counts.

ARM64 deploy jobs use the matching label set, at the ARM64 rates in the table:

jobs:
  deploy-arm:
    runs-on: warp-ubuntu-latest-arm64-4x
    steps:
      - uses: actions/checkout@v4
      - run: ./release/rollout.sh

On BYOC, the same job runs on a custom runner you define in your own account. Custom runners are referenced by their full Runner ID, which carries the warp-custom- prefix, as described in the BYOC documentation:

jobs:
  deploy:
    runs-on: warp-custom-deploy-use1
    steps:
      - uses: actions/checkout@v4
      - name: Pull release artifacts from S3
        run: aws s3 sync "s3://acme-releases/checkout-api/$GITHUB_SHA" ./release
      - name: Roll out
        run: ./release/rollout.sh

Getting to the enterprise outcome takes four steps.

1. Run the workflows on WarpBuild runners first. Change runs-on to a warp- label, merge, and confirm the jobs behave. Set up an AWS account connection and a stack first if you are going the BYOC route, following the BYOC setup guide or the AWS BYOC walkthrough.
2. Measure the current transfer line. In AWS Cost Explorer, filter by the data transfer usage types on the accounts that hold your registries and artifact buckets, and group by usage type over the last three full months. Cost allocation tags on the registry and bucket resources make the GitHub Actions share separable from production traffic.
3. Take the qualification path. Enterprise enablement runs through a conversation with the WarpBuild team, so bring the transfer numbers and the deploy-job counts from step 2.
4. Re-measure after two weeks on the enterprise tier, using the same Cost Explorer filter and the same grouping. Compare the transfer line to the baseline from step 2 and keep both screenshots with your cost review notes.

FAQ

Does zero egress apply to macOS runners?

No. The region-specific infrastructure callout in the WarpBuild cloud runners documentation states that it is not applicable to macOS instances. Linux x64, Linux ARM64, and Windows deploy jobs are the workloads this covers.

Does this apply to BYOC runners or to WarpBuild-hosted runners?

Both. On the enterprise tier, zero egress applies whether your runners live in your cloud or ours. BYOC runs on AWS, GCP, and Azure, and the WarpBuild-hosted fleet carries the same runner labels either way.

Which line items on my cloud bill does this affect?

The data transfer charges your provider raises when GitHub Actions jobs pull images and artifacts out of stores such as ECR and S3 during deployments. Compute, storage, and request charges in your account are unchanged.

Do I have to change my workflow files?

No. The runs-on labels stay the same, the steps stay the same, and runner time stays billed per minute. Enterprise qualification happens outside the workflow file.