What is Docker BuildKit? Explained Simply (2026)

If you've ever waited for a slow Docker build, or wondered why your image sizes keep growing, BuildKit is the answer. Docker BuildKit is the modern build engine that replaced the legacy builder — and it's enabled by default since Docker 23.

Here's what it actually does.

What BuildKit Is

BuildKit is Docker's next-generation image build engine. It was introduced as an experimental feature in Docker 18.09 and became the default in Docker 23.0.

The old builder ran build steps one at a time, in order, with no parallelism. BuildKit changed that entirely.

In one sentence: BuildKit is a smarter, faster, and more secure way to build Docker images.

How It Differs from the Old Builder

Old Builder (Classic)

Step 1: FROM ubuntu
Step 2: RUN apt-get update
Step 3: COPY app/ /app
Step 4: RUN npm install

• Sequential — one step at a time
• Every step runs even if nothing changed
• Build secrets stored in image layers (security risk)
• No parallel builds for multi-stage Dockerfiles

BuildKit

• Parallel execution — independent stages run simultaneously
• Better caching — only rebuilds what actually changed
• Secrets management — secrets never written to image layers
• Cache mounts — package manager caches persist between builds
• SSH forwarding — use SSH agent inside builds without copying keys

Enabling BuildKit

Docker Desktop

BuildKit is enabled by default since Docker Desktop 4.x and Docker Engine 23+.

# Check your Docker version
docker --version
 
# BuildKit is default in Docker 23+. Verify:
docker buildx version

Older Docker versions — enable manually

# Per-build
DOCKER_BUILDKIT=1 docker build -t myapp .
 
# Permanently in daemon.json
# /etc/docker/daemon.json
{
  "features": {
    "buildkit": true
  }
}

Key Features Explained

1. Cache Mounts (Biggest Speed Win)

Cache mounts let package managers reuse their download cache between builds. Without this, every npm install or pip install re-downloads everything from scratch.

# Without cache mount — downloads all packages every build
RUN npm ci
 
# With BuildKit cache mount — reuses node_modules cache
RUN --mount=type=cache,target=/root/.npm \
    npm ci

Python example:

RUN --mount=type=cache,target=/root/.cache/pip \
    pip install -r requirements.txt

Go example:

RUN --mount=type=cache,target=/go/pkg/mod \
    go mod download

This alone can cut build times by 50–80% for builds with large dependency trees.

2. Build Secrets (No More Hardcoded Credentials)

The old way of passing secrets into builds — environment variables or ARGs — stored them in image layers. Anyone with access to the image could extract them.

BuildKit secrets are never stored in layers:

# Mount a secret that's only available during this RUN step
RUN --mount=type=secret,id=github_token \
    GITHUB_TOKEN=$(cat /run/secrets/github_token) \
    npm install --registry https://npm.pkg.github.com

Pass the secret at build time:

docker build \
  --secret id=github_token,src=~/.github_token \
  -t myapp .

The secret is available during the build step but is never written to the image.

3. SSH Forwarding

Clone private Git repos during builds without copying your SSH key into the image:

FROM node:20
 
RUN --mount=type=ssh \
    git clone git@github.com:myorg/private-repo.git /app

# Build with SSH agent forwarding
docker build --ssh default -t myapp .

Your SSH key stays on your machine.

4. Parallel Multi-Stage Builds

Multi-stage Dockerfiles are common for separating build and runtime images. BuildKit runs independent stages in parallel:

# Stage 1: build frontend
FROM node:20 AS frontend-build
WORKDIR /app
COPY frontend/ .
RUN npm ci && npm run build
 
# Stage 2: build backend (runs IN PARALLEL with stage 1)
FROM golang:1.22 AS backend-build
WORKDIR /app
COPY backend/ .
RUN go build -o server .
 
# Final stage
FROM alpine
COPY --from=frontend-build /app/dist /static
COPY --from=backend-build /app/server /server

Old builder: sequential (frontend, then backend). BuildKit: both simultaneously.

5. .dockerignore Improvements

BuildKit respects .dockerignore more precisely and transfers only the files that are actually needed for each build stage.

Using BuildKit with GitHub Actions

- name: Set up Docker Buildx
  uses: docker/setup-buildx-action@v3
 
- name: Build and push
  uses: docker/build-push-action@v6
  with:
    context: .
    push: true
    tags: myapp:latest
    cache-from: type=gha
    cache-to: type=gha,mode=max

The type=gha cache stores BuildKit cache in GitHub Actions cache — so subsequent pipeline runs reuse it.

Common BuildKit Commands

# Build with BuildKit (default in modern Docker)
docker build -t myapp .
 
# Use docker buildx (extended BuildKit)
docker buildx build -t myapp .
 
# Build for multiple platforms
docker buildx build --platform linux/amd64,linux/arm64 -t myapp .
 
# Build with a secret
docker build --secret id=mykey,src=./key.txt -t myapp .
 
# Inspect build cache
docker buildx du
 
# Clear build cache
docker buildx prune

BuildKit vs Buildx

These terms are often confused:

Buildx adds extra features on top of BuildKit: multi-platform builds, multiple builders, remote builders.

When BuildKit Makes the Biggest Difference

• Large dependency installs — cache mounts save the most time here
• Multi-stage builds — parallelism speeds up complex pipelines
• CI/CD pipelines — GHA/GitLab cache integration
• Private packages — secrets and SSH mounts are more secure
• Multi-architecture images — ARM + AMD64 from one command

BuildKit is not a separate tool you install — it's already in your Docker. You just need to use its features intentionally.

Related: Docker Security Best Practices | GitHub Actions CI/CD Pipeline Tutorial | Docker Compose Complete Guide

Affiliate note: Docker Desktop includes BuildKit and Buildx out of the box. For CI/CD pipelines, GitHub Actions has native BuildKit cache support via type=gha.