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.

1. Set your API key as an environment variable:

   export WARPBUILD_API_KEY="your-api-key"

2. 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')

3. 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

4. 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

5. 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.