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.
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
Using WarpBuild's Build Push Action (Recommended)
WarpBuild provides a drop-in replacement for the widely used docker/build-push-action
. Our action automatically sets up the WarpBuild's Remote Docker builders for you.
Note: We recommend that you remove the
docker/setup-buildx-action
step from your workflow if you are only using it to setup builders.
- name: Setup Buildx
- uses: docker/setup-buildx-action@v3
name: Docker Build Push Action
- uses: docker/build-push-action@v6
+ uses: Warpbuilds/build-push-action@v6 # Uses WarpBuild Docker Builders
with:
context: .
push: true
tags: user/app:latest
+ profile-name: "super-fast-builder" # Specify the builder profile to use
Here's how you can use the Warpbuilds/build-push-action
in your workflows, whether you are using WarpBuild Runners or non-WarpBuild Runners.
jobs:
build:
runs-on: warp-ubuntu-latest-x64-4x
steps:
- uses: actions/checkout@v3
- name: Build and push
uses: Warpbuilds/build-push-action@v6
with:
context: .
push: true
tags: user/app:latest
profile-name: "super-fast-builder"
api-key: ${{ secrets.WARPBUILD_API_KEY }} # Not required for WarpBuild Runners
Using WarpBuild's Docker Configure Action
For users wanting more control over their workflows, WarpBuild provides a docker-configure
action. This action sets up the builder for you in the VM and outputs all their details which you can then use in your workflow. Although, we recommend using the Warpbuilds/build-push-action
as it is easier to use, this action allows you to use builders with your custom steps.
With WarpBuild Runners
jobs:
build:
runs-on: warp-ubuntu-latest-x64-4x
steps:
- uses: actions/checkout@v4
- - name: Setup Buildx
- - uses: docker/setup-buildx-action@v3
+ - name: Configure WarpBuild Docker Builders
+ uses: Warpbuilds/docker-configure@v1
+ with:
+ api-key: ${{ secrets.WARPBUILD_API_KEY }} # Not required on WarpBuild Runners
+ profile-name: "super-fast-builder"
- name: Custom Build docker image
run: |
...
Learn more about the outputs of the docker-configure
action in the docker-configure action docs.
From CLI
You can use WarpBuild's Docker builders directly from your CLI.
-
Set your API key as an environment variable:
export WARPBUILD_API_KEY="your-api-key"
-
Assign builders from your profile:
# Request a builder assignment
RESPONSE=$(curl -s -X POST \
-H "Content-Type: application/json" \
-H "Authorization: Bearer $WARPBUILD_API_KEY" \
-d '{"profile_name": "your-profile-name"}' \
https://api.warpbuild.com/api/v1/builders/assign)
# Get all builder IDs (we'll use the first one for this example)
BUILDER_ID=$(echo $RESPONSE | jq -r '.builder_instances[0].id') -
Get the builder details and certificates:
# Get builder details
DETAILS=$(curl -s -H "Authorization: Bearer $WARPBUILD_API_KEY" \
https://api.warpbuild.com/api/v1/builders/$BUILDER_ID/details)
# Extract connection information
HOST=$(echo $DETAILS | jq -r '.metadata.host')
# Create certificate directory
CERT_DIR="$HOME/.docker/warpbuild/$BUILDER_ID"
mkdir -p $CERT_DIR
# Save certificates
echo "$DETAILS" | jq -r '.metadata.ca' > $CERT_DIR/ca.pem
echo "$DETAILS" | jq -r '.metadata.client_cert' > $CERT_DIR/cert.pem
echo "$DETAILS" | jq -r '.metadata.client_key' > $CERT_DIR/key.pem -
Create a buildx instance with your builder:
docker buildx create --name "warpbuild" \
--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 -
Use the builder for your Docker builds:
docker buildx build --builder warpbuild -t myimage:latest .
You can now use this builder for faster Docker builds directly from your terminal!
Working with multiple builders
If your assignment returns multiple builders, you can set up additional nodes:
# For a second builder
BUILDER_ID_2=$(echo $RESPONSE | jq -r '.builder_instances[1].id')
# Get builder details
DETAILS_2=$(curl -s -H "Authorization: Bearer $WARPBUILD_API_KEY" \
https://api.warpbuild.com/api/v1/builders/$BUILDER_ID_2/details)
# Extract connection information
HOST_2=$(echo $DETAILS_2 | jq -r '.metadata.host')
# Create certificate directory
CERT_DIR_2="$HOME/.docker/warpbuild/$BUILDER_ID_2"
mkdir -p $CERT_DIR_2
# Save certificates
echo "$DETAILS_2" | jq -r '.metadata.ca' > $CERT_DIR_2/ca.pem
echo "$DETAILS_2" | jq -r '.metadata.client_cert' > $CERT_DIR_2/cert.pem
echo "$DETAILS_2" | jq -r '.metadata.client_key' > $CERT_DIR_2/key.pem
# Append second builder to existing buildx instance
docker buildx create --name "warpbuild" \
--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" \
tcp://$HOST_2
With multiple builders configured, your buildx instance can distribute build workloads more efficiently.
Multi platform builds
WarpBuild supports multi-platform builds for Docker images. You can specify the platforms you want to build for using the platforms
option in the docker/build-push-action
.
Note: Make sure that the builder profile being used has both architectures enabled in WarpBuild UI.
platforms: linux/amd64,linux/arm64
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"
Is the size of the Docker machine related to the the GitHub runner?
No, the size of the Docker machine is not limited by or related to the size of the GitHub runner used. It is determined by the size of the builder profile that you have selected.
Do I get charged for both the GitHub runner and the WarpBuild Docker builder runtime?
Yes. These are two separate, independent resources and you will be charged for both.
exec format error
while building for arm64 / multi-platform builds
This is likely because the builder profile does not have the correct architectures selected for your builder profile. Ensure the builder profile has both the architectures enabled.