7 New Dockerfile Features You Should Know About

One of the most significant security improvements in modern Docker builds is the ability to use secrets during build time without embedding them in the final image.

# syntax=docker/dockerfile:1.4
FROM alpine
RUN --mount=type=secret,id=mysecret,dst=/root/.secret \
    cat /root/.secret

And then build the image with:

$ echo "MY_SECRET_VALUE" > mysecret.txt
$ DOCKER_BUILDKIT=1 docker build --secret id=mysecret,src=mysecret.txt .

This solves a critical security issue in Docker builds. Previously, developers had to choose between:

• Hard-coding secrets in Dockerfiles (extremely insecure)
• Using build arguments (which remain visible in image history)
• Complex multi-stage build patterns

With secret mounts, you can securely use:

• API keys for downloading resources
• Private repository credentials
• Certificates and keys
• Any sensitive data needed during build but not at runtime

A seemingly small but highly useful feature is the ability to use ARG instructions before FROM in your Dockerfile, which allows you to parameterize base images.

# Use ARG before FROM to define base image parameters
ARG NODE_VERSION=16
ARG ALPINE_VERSION=3.16

# Use the ARG values in the FROM instruction
FROM node:${NODE_VERSION}-alpine${ALPINE_VERSION}

# The rest of your Dockerfile
WORKDIR /app
COPY . .
RUN npm install
CMD ["npm", "start"]

This feature enables several powerful use cases:

• Create matrix builds with different base images
• Centralize version management
• Simplify CI/CD pipelines with parameterized builds
• Test application compatibility across different runtime versions

You can override these arguments at build time:

$ docker build --build-arg NODE_VERSION=18 --build-arg ALPINE_VERSION=3.17 .

This approach is excellent for maintaining a single Dockerfile that can adapt to different environments or testing requirements, significantly reducing duplication in your containerization code.

BuildKit introduced the --link flag for COPY commands, which enhances layer caching and makes your builds faster by tracking content changes more efficiently.

# syntax=docker/dockerfile:1.4
FROM node:18-alpine AS builder
WORKDIR /app
COPY --link package*.json ./
RUN npm ci
COPY --link . .
RUN npm run build

FROM nginx:alpine
COPY --link --from=builder /app/dist /usr/share/nginx/html

The --link flag changes how BuildKit tracks dependencies and can lead to more efficient caching. Rather than invalidating cache based on metadata changes (like file timestamps), it focuses on actual content changes.

Benefits include:

• More reliable cache hits, even when file metadata changes
• Improved performance when using --from in multi-stage builds
• Better parallelization of build steps

This feature is particularly valuable in CI/CD environments where you want consistent, predictable build behavior regardless of how or when files were updated.

BuildKit provides granular control over network access during build steps with the --network flag for RUN commands, helping to create more secure and deterministic builds.

# syntax=docker/dockerfile:1.4
FROM python:3.10-slim

# No network access for this step
RUN --network=none mkdir -p /app/src

# Default network for this step
COPY requirements.txt .
RUN --network=default pip install -r requirements.txt

# No network for security-sensitive operations
RUN --network=none adduser --disabled-password --gecos '' appuser

COPY . .
USER appuser
CMD ["python", "app.py"]

The --network flag accepts several values:

• default: Standard Docker bridge network access
• none: No network access (isolated)
• host: Use the host network (careful, security implications)
• custom-network-name: A specific Docker network

This feature offers important benefits:

• Enhanced security by isolating build steps that don't need network access
• Improved build determinism by controlling network dependencies
• Better error detection for hidden network dependencies
• Ability to connect to custom networks for specialized build requirements

# Enable BuildKit for a single build
DOCKER_BUILDKIT=1 docker build .

# Enable BuildKit by default in Docker daemon
# Edit /etc/docker/daemon.json:
{
  "features": {
    "buildkit": true
  }
}