How Is a Remote Docker Builder Billed?
A remote Docker builder bills per minute for the session it stays up, from $0.06 per minute, separate from the GitHub Actions runner minutes a job spends.
A remote Docker builder is billed per minute for the session it stays up, at the rate attached to the builder profile size you picked, from $0.06 per minute for a 16 vCPU profile to $0.88 per minute for a 192 vCPU profile with 2TB of disk. That charge is separate from the GitHub Actions runner minutes the job spends, so a job that offloads its image build to a builder produces two lines on the invoice instead of one.
Answer
A session is measured from when the builder action starts until the job completes, per the Docker builders documentation, checked on 2026-08-13. The meter starts when Warpbuilds/docker-configure, Warpbuilds/build-push-action, or Warpbuilds/bake-action requests the builder, and it stops when the job finishes and the post-action steps complete. Nothing about the runner size changes that rate: the builder is a separate VM whose size comes from the profile you selected in the WarpBuild dashboard.
These are the profile sizes and their per-minute rates, from the pricing page and the Docker builders documentation, checked on 2026-08-13.
| Builder profile | Disk | Architectures | Price per minute |
|---|---|---|---|
| 16 vCPU, 32GB RAM | 100GB | amd64, arm64, multi | $0.06 |
| 32 vCPU, 64GB RAM | 200GB | amd64, arm64, multi | $0.12 |
| 64 vCPU, 128GB RAM | 200GB | amd64, arm64, multi | $0.24 |
| 96 vCPU, 192GB RAM | 600GB | amd64 only | $0.36 |
| 96 vCPU, 192GB RAM | 2TB | amd64 only | $0.52 |
| 192 vCPU, 384GB RAM | 600GB | amd64 only | $0.72 |
| 192 vCPU, 384GB RAM | 2TB | amd64 only | $0.88 |
arm64 and multi-arch profiles support a maximum size of 64 vCPU, so the last four rows apply to amd64-only profiles. The disk column is the builder VM's own disk, which is where the persistent layer cache for that profile lives.
The two-line point is worth stating plainly, because it surprises teams the first time they read an invoice. The runner is billed for the whole job, including the minutes it waits on the builder, and the builder is billed for the session it holds. Both lines are visible in the reports view: the reports documentation describes a Billing section with separate CI, Docker Builder, and Cache tabs, where the Docker Builder table gives one row per session showing profile, architecture, duration, and cost. The companion answer on paying for both the runner and the Docker builder covers that split in more depth.
Detail
A worked example with both lines
One job builds and pushes an image on a 4 vCPU Linux runner, using a 32 vCPU builder profile. The job runs for 9 minutes end to end. The checkout and setup steps take the first minute, so the builder session covers 8 of those minutes.
name: image
on:
push:
branches: [main]
jobs:
build:
runs-on: warp-ubuntu-latest-x64-4x
steps:
- uses: actions/checkout@v5
- name: Build and push
uses: Warpbuilds/build-push-action@v6
with:
context: .
push: true
tags: ghcr.io/acme/app:${{ github.sha }}
profile-name: "app-images"Rates for both lines come from the pricing page, checked on 2026-08-13.
| Line | Resource | Duration | Rate | Cost |
|---|---|---|---|---|
| Runner minutes | warp-ubuntu-latest-x64-4x | 9 min | $0.008/min | $0.072 |
| Builder session | 32 vCPU, 64GB RAM, 200GB disk | 8 min | $0.12/min | $0.960 |
| Total | $1.032 |
At 400 merges a month that workflow costs $412.80, and the builder carries 93 percent of it. The runner line stays small because the per-minute runner rate, $0.008, sits far below the per-minute builder rate, $0.12, at this pairing. Rate-shopping the builder profile moves the total far more than rate-shopping the runner does.
Sizing the builder is arithmetic on the same two numbers. Doubling the profile size doubles the per-minute rate, so a larger profile pays for itself only when it cuts session length by more than half. If a build takes 14 minutes on the 16 vCPU profile, it costs $0.84 of builder time; if the 32 vCPU profile finishes the same build in 8 minutes, it costs $0.96 and returns the image 6 minutes earlier. Both totals belong in the decision, along with the runner minutes that shrink alongside the session.
When many jobs share one session
Each builder profile maps to one dedicated builder VM, and jobs that name the same profile run on that VM in parallel. Overlapping jobs share one session, billed from the first job's builder start to the last job's completion. The documentation works through two jobs whose windows overlap and bills the pair as a single session spanning both.
That changes how a fan-out workflow prices out. Ten parallel image jobs on one 32 vCPU profile, overlapping inside a 12 minute window, cost $1.44 of builder time in total rather than $1.44 each. The runner side does not consolidate: ten jobs on warp-ubuntu-latest-x64-4x for 12 minutes each bill 120 runner minutes at $0.008, or $0.96. Splitting the same ten jobs across two profiles doubles the builder line and splits the layer cache, which is usually the wrong trade.
Multi-architecture profiles work the other way. Each architecture runs on its own builder instance, so a multi-arch build opens one session per architecture and bills them independently, and those sessions stay alive until the post-action steps finish.
Idle time is bounded when a builder runs through the GitHub Actions integration. Builders carry a built-in timeout so accounts are not charged for idle builders, and the documentation recommends invoking the configure action immediately before the build step. The CLI path is the exception. A builder assigned through the API bills until you call the session-complete endpoint, so a script that exits without completing the session keeps the meter running.
Where each line appears
The reports view is where the two lines separate. The Docker Builder tab shows total cost and total session count for the period, a daily chart grouped by profile or architecture, and a table of individual sessions with profile, architecture, duration, and cost. The CI tab shows per-job runner cost with execution time and billed time side by side. Every tab filters by date range and exports to CSV, which is the practical way to attribute builder spend back to the repositories that trigger it.
What the bill never adds
Builders attach to jobs from any platform. Profile sizes and configuration options are listed on the remote Docker builders page, and Docker builds on GitHub Actions covers the full setup around them.
Related Questions
Do I pay for the GitHub Actions runner and the Docker builder at the same time?
Yes. The runner and the builder are two separate resources and both are charged. The runner bills per minute for the job, and the builder bills per minute for the session it stays up, so a job that offloads its image build carries two lines. See paying for both the runner and the Docker builder for how that lands on a monthly invoice.
Does a builder session cost more when ten jobs share it?
No. Concurrent jobs that name the same builder profile share one session, billed from the first job's builder start to the last job's completion. Ten parallel jobs on a 32 vCPU profile for a 12 minute window cost $1.44 of builder time in total, and each job still bills its own runner minutes. The Docker builds on GitHub Actions page covers profile layout for fan-out workflows.
How is a multi-architecture build billed?
Each architecture runs on a separate builder instance, so a multi-arch profile opens one session per architecture and bills them independently. arm64 and multi-arch profiles support a maximum size of 64 vCPU, so the 96 vCPU and 192 vCPU rows apply to amd64-only profiles. Sizes per architecture are on the remote Docker builders page, and the rate list is on the pricing page.
Start with $10 in free credits
Change the runner label in your workflow and keep the rest of your GitHub Actions setup. Runner time is billed per minute.