Skip to main content

Docker Builders

WarpBuild provides powerful Docker builders that significantly accelerate your Docker build times, delivering superior performance for your containerization workflow.

Features

  • 🚀 Fast Docker builds with WarpBuild's remote builder nodes.
  • 🔄 Automatic Docker BuildX integration.
  • 🔐 Secure TLS authentication.
  • 🌐 Works with both WarpBuild runners and non-WarpBuild runners.
  • 🔌 Integrate anywhere via API, supporting local development and various CI platforms (GitHub, GitLab, Bitbucket, Buildkite, etc.).
  • 🏗️ Multi-architecture builds (amd64, arm64) out of the box - coming soon.

See it in Action

Docker builder in action

Experience up to 50% faster Docker builds compared to traditional solutions. Our optimized builder infrastructure handles the heavy lifting so your CI/CD pipeline runs more efficiently.

To get started with Docker builders, go to the Docker Builders page and create a builder profile.

View docker builders

Builder Types

WarpBuild offers two types of builders to suit your workflow needs:

  • Cached builders: Maintain state between builds, ideal for reducing build times across multiple runs.
  • Ephemeral builders: Created fresh for each build and destroyed afterward, perfect for isolated environments.

Concurrency

Concurrency is only applicable in case of cached builders. It is the number of concurrent builds that can be run on a builder profile. If you have a cached builder with concurrency set to 1, and you have 4 builds to run, the builds will be run one after the other.

It is recommended to start with a concurrency of 1 and then increase it if you are running into limits.

Pricing is per provisioned builder concurrency.

Usage

With WarpBuild Runners

jobs:
build:
runs-on: warp-ubuntu-latest-x64-4x
steps:
- uses: actions/checkout@v3

- name: Configure WarpBuild Docker Builders
uses: Warpbuilds/docker-configure@v1
with:
profile-name: "super-fast-builder"

- name: Build and push
uses: docker/build-push-action@v4
with:
context: .
push: true
tags: user/app:latest

With Non-WarpBuild GitHub Runners

When using non-WarpBuild GitHub runners, you need to provide an API key:

jobs:
build:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4

- name: Configure WarpBuild Docker Builders
uses: Warpbuilds/docker-configure@v1
with:
api-key: ${{ secrets.WARPBUILD_API_KEY }}
profile-name: "super-fast-builder"

- name: Build and push
uses: docker/build-push-action@v6
with:
context: .
platforms: linux/amd64,linux/arm64
push: true
tags: user/app:latest

For more information about the docker-configure action, see the docker-configure action docs.

Deleting a Builder Profile

You can delete a builder profile from the Docker Builders page. It is necessary to wait for all the builds to finish before deleting a builder profile.

Delete a builder profile

Pricing

Builder SizeBuilder TypeConcurrencyPricing
15xEphemeralUnlimited$0.04/min
30xEphemeralUnlimited$0.08/min
15xCached1-5$0.04/min per provisioned concurrency
30xCached1-5$0.08/min per provisioned concurrency

Any number of ephemeral builders can be provisioned in parallel.

Cached builders are billed per provisioned concurrency. For example, if you have a cached builder with provisioned concurrency of 3, each build will be charged $0.04 * 3 = $0.12 per minute.

The feature is currently in beta and the pricing is subject to change.

F.A.Q.

How does caching work for concurrent builds?

For caching behavior between concurrent builds, note that the cache is shared but eventually consistent. This means that layer caching from one build may not be immediately available to another concurrent build, but will be available for future builds after synchronization occurs.

Build summary doesn't get generated

At the moment, build summary will not be generated from docker/build-push-action. The action might also display a warning. This is expected and does not affect the build process.

We recommend to add the following env variables in docker/build-push-action to disable the build summary.

- name: Build and push
uses: docker/build-push-action@v6
env:
DOCKER_BUILD_RECORD_UPLOAD: false
DOCKER_BUILD_SUMMARY: false
DOCKER_BUILD_CHECKS_ANNOTATIONS: false

Docker Builder is timing out

Docker Builders have timeout built-in so that users don't get charged for builders that are idle. We recommend that you invoke the WarpBuilds/docker-configure action just before the build-and-push action or any other step that performs docker build.

How to use cache-to and cache-from with Docker Builders

When using Docker Builders, the cache-to and cache-from options are not required. A cached Docker Builder will automatically cache the layers and reuse them for subsequent builds.

- name: Older Docker WarpCache Backend
- uses: docker/build-push-action@v6
- with:
- context: .
- push: false
- tags: "alpine/warpcache:latest"
- cache-from: type=gha,url=http://127.0.0.1:49160/
- cache-to: type=gha,url=http://127.0.0.1:49160/,mode=max

+ name: New WarpBuild Docker Builders
+ uses: Warpbuilds/docker-configure@v1
+ with:
+ profile-name: "super-fast-builder"

+ name: Build and push
+ uses: docker/build-push-action@v6
+ with:
+ context: .
+ push: false
+ tags: "alpine/warpcache:latest"

When spinning a remote Docker build on a Warp Ubuntu machine, is the size of the Docker machine limited by the size of the Warp Ubuntu runner?

No, the size of the Docker machine is not limited by the size of the Warp Ubuntu runner. It is determined by the size of the builder profile that you have selected.

How does billing work in the scenario above? Specifically, if the Warp runner is active and waiting for the Docker run to complete (which might take most of the total build time), will I be charged for both the Warp runner and the Docker builder runtime concurrently?

Yes, you will be charged for both the Warp runner and the Docker builder runtime.