Remote Docker Builders: Sizes and Pricing

WarpBuild remote Docker builder profiles come in seven sizes, from 16 vCPU with 32GB memory and 100GB disk at $0.06 per minute up to 192 vCPU with 384GB memory and 2TB disk at $0.88 per minute. Each profile maps to one dedicated builder VM with a persistent layer cache, and it bills per session, measured from the first job start to the last job completion on that profile.

Two rules shape every size and price decision below. Architecture caps the catalog: arm64 and multi-arch profiles stop at 64 vCPU. Billing is per session rather than per job, so several jobs sharing a profile share one billable stretch of time.

Catalog

A builder profile is created once in the dashboard or through the API, then referenced from workflows by name.

Every size in the catalog, with the architectures each size supports:

Sizes and rates come from the WarpBuild Docker builders documentation and were verified on 2026-08-13.

The architecture limit

The architecture selected on a builder profile decides which half of the catalog you can reach. arm64 profiles and multi-arch profiles cap at 64 vCPU. The 96 vCPU and 192 vCPU sizes are amd64 only, in both the 600GB and the 2TB disk variants.

This limit has a workaround that also changes the bill. Instead of one multi-arch profile, keep two profiles: an amd64-only profile that can grow past 64 vCPU and a separate arm64 profile at 64 vCPU or below. The amd64 image then gets the larger machine, and each profile keeps its own layer cache. Teams building at scale on both architectures already run this shape. Samaya AI runs tens of Docker builds per pull request across ARM64 and x64 on WarpBuild remote Docker builders, serving 10,000 or more seats.

Disk is the cache budget

The disk column is the size of the persistent layer cache the profile can hold. A profile that caches layers for one service fits comfortably in 100GB. A profile serving a monorepo where a dozen images share base layers and each final image is several gigabytes is what the 600GB and 2TB variants exist for. When the disk fills, older layers are evicted and the builds that needed them run cold again.

That cache is the reason the machine is remote in the first place.

The cache has a lifetime. A builder profile that is not used for 10 days has its cache reset automatically. Low-traffic profiles, for example one attached to a release workflow that runs monthly, will keep starting cold. Point those workflows at a profile that a busier workflow also uses, so the cache stays warm between releases.

Concurrency inside one profile

One builder profile is one VM, and several jobs pointing at that profile build on it in parallel. Generally available Linux and Windows runners do not have plan-level concurrency caps; the builder profile is instead constrained by its own machine size. The documented sizing guidance is roughly 8 vCPU and 16GB memory per concurrent build job, which is where the vCPU column turns into a capacity number: a 64 vCPU profile sizes for around eight builds at once, a 192 vCPU profile for around twenty-four.

Exceeding that guidance does not fail the build. The builds share cores and each one takes longer, which shows up as a longer session and a larger bill.

Pricing

Pricing is purely usage based. There is no base subscription fee, no platform fee, and no seat fee. Builder time is billed per minute of session, and the table below turns the per-minute rate into the three numbers teams usually want next.

Signup includes $10 free credits, which is the last column: enough session time on a 16 vCPU profile to measure a real workload before you commit to a size.

What counts as a session

A session starts when the builder action starts and ends when the job completes. Multiple concurrent jobs on the same builder profile share one session, billed from the first job start to the last job completion.

Take two jobs on the same amd64 profile with overlapping runtimes. Job A takes the builder at minute 0 and finishes at minute 8. Job B takes the same builder at minute 3 and finishes at minute 12. That bills as one session of 12 minutes rather than as 8 minutes plus 9 minutes. On a 32 vCPU profile at $0.12 per minute the session costs $1.44.

The practical consequence is that a step placed after the build keeps the session open. A push to a slow registry, a scan, or a long post-action step all extend the last job completion time and therefore the session. Move work that does not need the builder out of the window where the builder is held.

Two resources, two lines on the bill

The runner and the builder are separate, independent resources, and both are charged. The runner bills per minute at its own catalog rate. The builder bills per session at the profile rate.

Worked example: a pull request builds four service images in parallel on one 32 vCPU profile, with each job running on warp-ubuntu-latest-x64-4x.

Only the runner line has a GitHub-hosted equivalent, since GitHub-hosted runners have no remote builder product to price against. Every WarpBuild rate on this page comes from the WarpBuild pricing page and the docs, checked on 2026-08-13.

Multi-arch billing

A multi-arch build runs each architecture on its own builder instance, which produces one session per architecture on the same profile. The two sessions are billed independently, and each stays alive until its post-action steps complete.

On a 64 vCPU multi-arch profile at $0.24 per minute with a 6-minute build per architecture, that is 2 sessions x 6 minutes x $0.24, or $2.88 of builder time per pull request, plus runner minutes. Budget multi-arch at double the single-architecture session cost, then compare it against splitting the work across two single-architecture profiles where the amd64 side can use a larger machine.

Structure of the bill

Nothing here requires a plan change or a seat count. Docker builder sessions appear on their own tab under Reports, with each row showing one session, its profile, its architecture, its duration, and its cost, so the profile running long sessions for short builds is easy to spot. SSO is available for a flat $250 per month, whatever the user count.

Configuration

The builder profile is selected by name from the workflow. Swap docker/build-push-action for Warpbuilds/build-push-action@v6 and pass profile-name.

name: build-image
on: push

jobs:
  image:
    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: registry.example.com/app:${{ github.sha }}
          profile-name: "app-images-32x"
          timeout: 600000

Remove any docker/setup-buildx-action step that exists only to create a builder, and drop cache-from and cache-to. A builder profile caches layers on its own disk and reuses them on the next build without cache flags.

Multi-arch uses the same action with a platforms input, against a profile that has both architectures enabled:

      - name: Build and push multi-arch
        uses: Warpbuilds/build-push-action@v6
        with:
          context: .
          push: true
          platforms: linux/amd64,linux/arm64
          tags: registry.example.com/app:${{ github.sha }}
          profile-name: "app-images-multi-64x"

Builder size is independent of runner size

The size of the builder profile has no relationship to the size of the GitHub Actions runner that drives it. The runner in the example above is a 4 vCPU machine that checks out the repository and calls the action, while the build itself runs on the 32 vCPU builder. Picking a larger runner will not make the image build faster, and picking a smaller one will not make it cheaper beyond the runner line.

The two resources are billed separately, so size each against its own job. Size the runner for checkout, test steps, and whatever else the job does. Size the builder for the images, using the concurrency guidance above.

Builders reach beyond WarpBuild Cloud runners. WarpBuild provides Linux x64, Linux ARM64, macOS, and Windows runners, and a builder profile can also be driven from a GitHub-hosted runner or a BYOC runner by adding an api-key input, since BYOC runs on AWS, GCP, and Azure.

For the full setup walkthrough, including the bake action and running builds outside GitHub Actions, read the remote Docker builders guide. Language-agnostic build patterns and matrix layouts are covered on Docker builds on GitHub Actions. If you are still deciding between a registry cache and a remote builder, start with choosing a Buildx cache backend on GitHub Actions, and for the concept on its own see what is a remote Docker builder. Runner labels and their own rates are in the WarpBuild cloud runners documentation.

FAQ

What is the largest builder profile available for arm64 or multi-arch builds?

64 vCPU with 128GB memory and 200GB disk, at $0.24 per minute. arm64 and multi-arch builder profiles cap at 64 vCPU. The 96 vCPU and 192 vCPU sizes are available for amd64-only profiles.

How is a builder profile billed when several jobs build on it at the same time?

As one session. A builder session runs from the first job start to the last job completion on that profile, so a fan-out of parallel jobs sharing a profile produces a single billable stretch of time rather than one per job.

Does the builder layer cache expire?

Yes. A builder profile that goes unused for 10 days has its cache reset automatically. The next build after a reset runs cold and repopulates the cache on the profile disk.

Do I pay for the GitHub Actions runner and the builder separately?

Yes. The runner and the builder are two separate resources billed on two lines. The builder profile size is chosen independently of the runner size, so a 4 vCPU runner can drive a 192 vCPU builder profile.