Do I Pay for Both the Runner and the Builder?

Yes. A GitHub Actions job that uses a remote Docker builder holds two machines, and each one bills on its own line: the runner bills per minute for as long as the job runs, and the builder bills per session at the rate of its profile size. The Docker builders documentation states the builder half directly, and the runner half is the ordinary per-minute rate on the pricing page.

Answer

The two lines exist because the two resources are separate. The runner checks out the repository, runs tests, runs post-job steps, and issues the build request. The builder is a different virtual machine with its own disk and its own layer cache, and it does the image work. Neither one substitutes for the other, so both meters run.

The documentation is explicit about how each meter reads. Docker builders "are billed per session. A session is measured from when the builder action starts until the job completes", and concurrent jobs on one profile share a single session billed from the first job start to the last job completion (Docker builders documentation, checked on 2026-08-13). Runners bill per minute at the rate published for their label on the pricing page.

This is the runner line for the common sizes.

This is the builder line, for every profile size in the catalog.

Both tables come from the pricing page and the runner and builder documentation, checked on 2026-08-13. The remote Docker builder catalog carries the same builder rows with the sizing notes.

Detail

The two meters start at different moments

The runner meter starts when the job picks up a machine and stops when the job finishes. The builder meter starts when the builder action runs inside that job and stops when the job completes. The builder window therefore sits inside the runner window, and the overlapping stretch is billed on both lines at the same time.

That overlap is the part worth designing around. Minutes spent on checkout, dependency install, tests, and post-job steps are runner-only minutes. Minutes spent on the image build are runner minutes and builder minutes together.

One build job, both lines

Stated assumptions, so you can substitute your own measurements:

• One image build job on warp-ubuntu-latest-x64-4x at $0.008 per minute.
• The job runs 7 minutes end to end: 1 minute of checkout and setup, 5 minutes on the build step, 1 minute of post-job steps.
• The builder is a 32 vCPU profile with 64GB memory and a 200GB disk at $0.12 per minute.
• The builder action starts at minute 1 and the session ends when the job completes at minute 7, so the session is 6 minutes.

The builder is 93 percent of that total, which is the practical answer to "which line should I tune". Scale it to 400 builds a month arriving one at a time: 2,800 runner minutes at $22.40, plus 2,400 session minutes at $288.00, for $310.40.

Now change the arrival pattern and nothing else. If the same 400 builds arrive as 100 fan-outs of 4 jobs on one profile, and each fan-out holds the builder for 10 minutes, the builder line is 1,000 session minutes at $120.00 while the runner line stays at $22.40, for $142.40. Same builds, same profile, $168.00 of difference from scheduling, because concurrent jobs on one profile share a session and staggered jobs each open their own.

When the builder line pays for itself

The builder rate is higher per minute than a runner rate at the same shape: $0.12 per minute for a 32 vCPU builder profile against $0.064 per minute for warp-ubuntu-latest-x64-32x at 32 vCPU. The builder line earns that rate by removing minutes, and it removes minutes only while the layer cache on the profile disk stays warm across runs.

Here is the comparison on the same repository, with the build running on the runner in one case and on a builder in the other.

The $0.568 difference comes from the 14 minutes the warm cache removes rather than from a lower per-minute rate. Two conditions break that arithmetic. A profile that goes unused for more than 10 days has its cache reset automatically, so a repository that builds images weekly starts cold on most runs. A base image tag that gets republished on every build invalidates every layer below it, which produces a cold build while still opening a billable session.

Remote Docker builders are one part of the product surface, alongside snapshot runners, CI observability, an MCP server, and the Action Debugger, and each of those has its own line or its own included behavior on the bill.

Reading both lines in your own account

The reports documentation describes where the split shows up. The Billing section has separate CI, Docker Builder, and Cache tabs. The CI tab gives one row per job execution with repository, job name, runner label, execution time, billed time, and the runner and snapshot cost breakdown. The Docker Builder tab gives one row per session with profile, architecture, duration, and cost. Both tables filter by date range and export to CSV, which is the fastest way to check the session count against the job count and find the staggered builds.

Nothing else attaches to these two lines. Every rate is on the pricing page.

Related Questions

Does the runner keep billing while it waits on the builder?

Yes. The runner holds a machine for the whole job, including the stretch it spends waiting for the build to come back from the builder, so the two lines overlap in time. That is why a small runner paired with a large builder profile is usually the cheaper shape: the runner rate applies to every minute of the job, and the builder rate applies only to the session. How a remote Docker builder is billed works through the session boundaries in more detail.

Do I still pay a builder line on a GitHub-hosted runner?

Yes. Remote Docker builders work with runners WarpBuild does not operate, and the builder session is billed the same way whatever drives it. The runner minutes move to GitHub's bill instead of WarpBuild's, and the workflow passes an API key through the api-key input so the action can request a builder assignment (Docker builders documentation).

Does a multi-arch image produce two builder lines?

Yes. Each architecture runs on a separate builder instance, so a multi-arch build opens one session per architecture on the same profile and both are billed independently until the post-action steps finish. The runner line stays single, because one job drives both builds. Note also that arm64 and multi-arch profiles cap at 64 vCPU, so the 96 vCPU and 192 vCPU rows in the builder catalog are available for amd64-only profiles.