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
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.
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.
Pricing
Builder Size | Builder Type | Concurrency | Pricing |
---|---|---|---|
15x | Ephemeral | Unlimited | $0.04/min |
30x | Ephemeral | Unlimited | $0.08/min |
15x | Cached | 1-5 | $0.04/min per provisioned concurrency |
30x | Cached | 1-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.