Multi Platform Remote Docker Builders

A multi platform remote Docker builder profile assigns one builder instance per platform and joins those instances into a single Buildx instance, so linux/amd64 layers build on an amd64 machine and linux/arm64 layers build on an arm64 machine with no instruction translation anywhere in the build (Docker builders documentation, checked on 2026-08-13). Multi architecture profiles run in three sizes, 16, 32, and 64 vCPU at $0.06, $0.12, and $0.24 per minute, and a two platform build opens one billable session per architecture on the profile.

This page is the catalog and price reference for that shape. It lists the sizes a multi architecture profile can select, prices a two platform build at each size, shows the documented two builder join, and gives the signature that appears in a log when one platform quietly falls back to emulation.

Catalog

A builder profile is created once in the dashboard or through the API, has its architectures selected there, and is then referenced from workflows by name.

Architecture selection decides which half of the size catalog the profile can reach. These are the sizes a profile with both amd64 and arm64 enabled can use:

The 96 vCPU and 192 vCPU sizes, in both the 600GB and 2TB disk variants, are available on amd64-only profiles. A multi architecture profile therefore stops at 64 vCPU, 128GB memory, and 200GB disk. Sizes and rates come from the Docker builders documentation and were re-checked on 2026-08-13.

One instance per platform

The size in that table applies per instance. A 32 vCPU multi architecture profile driving a two platform build gets a 32 vCPU amd64 instance and a 32 vCPU arm64 instance, each with its own TLS certificates, its own disk, and its own persistent layer cache. Buildx sees them as two nodes of one builder, and BuildKit routes each platform's build graph to the node whose native architecture matches.

Two consequences follow from separate disks. The amd64 cache never warms an arm64 build, so each architecture pays its own cold start the first time a base image or a dependency layer changes. And the 10 day cache reset applies per profile, so a release-only multi platform workflow that fires monthly starts cold on both instances every time. Rates for every size are on the pricing page.

Sizing for two platforms

The documented sizing guidance is roughly 8 vCPU and 16GB memory per concurrent build job. Because each architecture lands on its own instance, the two halves of a single image do not contend with each other, and the guidance applies to concurrency within one architecture. A 32 vCPU multi profile sizes for about four concurrent amd64 builds and four concurrent arm64 builds at the same time.

Fan-out is where the ceiling bites. A pull request that builds six service images for both platforms puts six builds on each instance, which is past the guidance on a 32 vCPU profile. Nothing fails. The builds share cores, both sessions run longer, and the bill grows with the session length.

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 a two platform build runs two sessions in parallel, so the effective rate while both are alive is double the profile rate.

Signup includes $10 free credits, which is the last column: enough two platform build time on a 16 vCPU profile to measure a real image before committing to a size.

A pull request priced end to end

The runner and the builder are separate resources billed on separate lines. Take one image built for both platforms on every pull request, with a 9 minute job on warp-ubuntu-latest-x64-4x driving a 32 vCPU multi architecture profile, and a 7 minute build per architecture.

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

One multi profile or two single architecture profiles

The bill is close to identical either way, because either shape runs two instances and two sessions. The difference is the size ceiling and the cache. Two single architecture profiles let the amd64 side select 96 or 192 vCPU while the arm64 side stays at 64 vCPU or below, and each profile keeps its own cache lifetime. One multi profile keeps the workflow to a single profile-name and one dashboard entry. Pick the split when the amd64 image is the slow one and wants a machine larger than 64 vCPU.

Configuration

Enable both architectures on the builder profile first. A profile with one architecture enabled is what produces the failure modes at the end of this section.

In GitHub Actions, one step builds both platforms:

name: image

on:
  push:
    branches: [main]

jobs:
  build:
    runs-on: warp-ubuntu-latest-x64-4x
    permissions:
      contents: read
      packages: write
    steps:
      - uses: actions/checkout@v5

      - uses: docker/login-action@v3
        with:
          registry: ghcr.io
          username: ${{ github.actor }}
          password: ${{ secrets.GITHUB_TOKEN }}

      - name: Build and push both platforms
        uses: Warpbuilds/build-push-action@v6
        with:
          context: .
          push: true
          platforms: linux/amd64,linux/arm64
          tags: ghcr.io/acme/app:${{ github.sha }}
          profile-name: "app-images-multi-32x"
          timeout: 600000

Drop docker/setup-buildx-action and docker/setup-qemu-action from that job. Neither is needed once each platform has a native instance, and a stale setup-qemu-action is what turns a misconfigured profile into a slow build instead of a failed one. Drop cache-from and cache-to as well, since each instance caches layers on its own disk and reuses them on the next build.

Joining the two builders by hand

Outside GitHub Actions, the assignment API returns one builder instance per platform and you join them yourself. The first instance creates the Buildx instance and the second is appended as a node, which is how the single builder ends up carrying both platforms:

docker buildx create --name "$BUILDER_NAME" \
  --node "$BUILDER_ID" \
  --driver remote \
  --driver-opt "cacert=$CERT_DIR/ca.pem" \
  --driver-opt "cert=$CERT_DIR/cert.pem" \
  --driver-opt "key=$CERT_DIR/key.pem" \
  --use \
  tcp://$HOST

docker buildx create --name "$BUILDER_NAME" \
  --append \
  --node "$BUILDER_ID_2" \
  --driver remote \
  --driver-opt "cacert=$CERT_DIR_2/ca.pem" \
  --driver-opt "cert=$CERT_DIR_2/cert.pem" \
  --driver-opt "key=$CERT_DIR_2/key.pem" \
  --use \
  tcp://$HOST_2

Each instance needs its own certificate directory, taken from that instance's details response. Billing runs until the session is completed through the API, so pair every assignment with a completion call (Docker builders documentation).

When a platform falls back to emulation

A profile with only amd64 enabled has no aarch64 instance to route the arm64 graph to. What happens next depends on whether a binfmt handler is registered in the job.

With no handler, the first RUN step of the arm64 stage fails with exec format error, which the WarpBuild docs list as the signature of a profile missing an architecture. With a handler registered, usually by a leftover docker/setup-qemu-action step, the arm64 stage runs under QEMU user mode emulation on the amd64 node, the build succeeds, and the only symptom is a long arm64 stage (Docker multi-platform build documentation).

Three checks separate the two cases:

• docker buildx ls lists the platforms of each node, and platforms reachable only through emulation carry a trailing asterisk (Docker multi-platform build documentation).
• The Docker builder sessions tab under Reports shows one session per architecture for a native two platform build. One session means one instance, which means one architecture is being emulated.
• The arm64 stage taking several times the amd64 stage on the same Dockerfile points at emulation rather than at the Dockerfile.

For the full size and rate catalog across all seven builder profiles, see remote Docker builder sizes and pricing. The native-runner alternative, where each architecture builds on a runner of its own architecture, is covered in multi platform Docker builds on native runners, and the tag joining step is in how do I push a manifest list from GitHub Actions. The short version of this page is do remote Docker builders support multi platform builds. WarpBuild provides Linux x64, Linux ARM64, macOS, and Windows runners, and their labels and rates are in the cloud runners documentation.

FAQ

What sizes can a multi platform builder profile use?

Three: 16 vCPU with 32GB memory and 100GB disk at $0.06 per minute, 32 vCPU with 64GB memory and 200GB disk at $0.12 per minute, and 64 vCPU with 128GB memory and 200GB disk at $0.24 per minute. The 96 vCPU and 192 vCPU sizes are amd64 only, so a multi architecture profile caps at 64 vCPU.

How is a two platform build billed?

As two sessions on the same profile, one per architecture, each billed at the profile rate until its post-action steps finish. A 6 minute build on both platforms against a 32 vCPU profile is 2 sessions x 6 minutes x $0.12, or $1.44 of builder time, plus the runner minutes on a separate line.

How do I tell whether the arm64 half really built natively?

Check the session count and the platform list. A native two platform build opens two sessions on the profile, one per architecture, and docker buildx ls shows both platforms without a trailing asterisk. One session, an asterisk on the second platform, or an exec format error in a RUN step all mean the profile has one architecture enabled.