DevKraken

Docker Tricks in 2026: Faster Builds, AI Tools, Secure Images, and Smarter Dev Workflows

Practical Docker tricks for 2026: Compose Watch, Buildx cache, Docker Scout, Hardened Images, Gordon, MCP Toolkit, and Docker Model Runner.

Soman Bandesha Updated 17 min read
Docker Tricks in 2026: Faster Builds, AI Tools, Secure Images, and Smarter Dev Workflows

Most Docker articles still explain docker run like it is the hard part. It is not.

The hard part is keeping builds fast, containers small, images secure, and local development close enough to production that you stop saying “but it worked on my machine.” In 2026, Docker is also moving into AI workflows with Gordon, Docker Model Runner, MCP Toolkit, and Compose model support.

This guide is practical. You can copy the examples, adjust them for your app, and use them in real projects.

Quick list of Docker tricks for 2026

Use these when you want a fast checklist:

Docker trickBest for
Compose WatchLive reload during local development
Multi-stage DockerfilesSmaller production images
Buildx cacheFaster local and CI builds
Docker Build CloudOffloading heavy builds
Docker ScoutFinding CVEs and base image problems
Docker Hardened ImagesStarting from safer production images
Non-root usersReducing container risk
Compose secretsAvoiding plain text secrets in YAML
GordonDebugging Docker issues with an AI agent
Docker MCP ToolkitRunning MCP servers for AI tools
Docker Model RunnerRunning local AI models with Docker
Compose modelsDeclaring AI models beside services

1. Use Compose Watch instead of rebuilding by hand

Keyword targets: docker compose watch, docker live reload, docker local development

If you edit code and keep running docker compose build manually, you are wasting time. Compose Watch can sync files into a running container, rebuild when dependency files change, or restart a service when config changes.

A simple Node.js example:

services:
  web:
    build: .
    ports:
      - "3000:3000"
    command: npm run dev
    develop:
      watch:
        - action: sync
          path: ./src
          target: /app/src

        - action: rebuild
          path: package.json

        - action: sync+restart
          path: ./config
          target: /app/config

Run it with:

docker compose up --watch

Use sync for source files. Use rebuild for dependency files such as package.json, pnpm-lock.yaml, requirements.txt, or go.mod. Use sync+restart for config changes where the container does not need a new image.

This one change makes Docker feel much less heavy during development.

2. Keep your Dockerfile boring and predictable

Keyword targets: dockerfile best practices, docker dockerfile optimization, docker production image

A good Dockerfile is not clever. It is boring in the best way. It installs only what it needs, copies files in the right order, runs as a normal user, and does not drag development tools into production.

Here is a cleaner Node.js Dockerfile:

# syntax=docker/dockerfile:1

FROM node:22-bookworm-slim AS deps
WORKDIR /app

COPY package*.json ./
RUN npm ci

FROM node:22-bookworm-slim AS build
WORKDIR /app

COPY --from=deps /app/node_modules ./node_modules
COPY . .
RUN npm run build

FROM node:22-bookworm-slim AS runner
WORKDIR /app

ENV NODE_ENV=production

COPY package*.json ./
RUN npm ci --omit=dev && npm cache clean --force

COPY --from=build /app/dist ./dist

USER node

EXPOSE 3000

CMD ["node", "dist/server.js"]

Why this works:

  • Dependencies are installed before the full source copy, so Docker can reuse cache more often.
  • Build tools stay in the build stage.
  • The final image only gets what it needs to run.
  • The app runs as the built-in node user, not root.

Do not over-optimize too early. Start with this pattern, then measure build time and image size.

3. Add a real .dockerignore

Keyword targets: dockerignore file, docker build context, reduce docker build time

Docker sends the build context to the builder. If your context includes node_modules, .git, logs, local database files, or test output, every build starts with extra baggage.

Use this as a starting point:

.git
.gitignore

node_modules
dist
build
coverage

.env
.env.*
*.log

.DS_Store
.idea
.vscode

tmp
.cache

For Python projects:

.git
__pycache__
*.pyc
.venv
venv
.env
.pytest_cache
.mypy_cache
dist
build
*.egg-info

For Laravel or PHP projects:

.git
vendor
node_modules
.env
storage/logs
storage/framework/cache
storage/framework/sessions
storage/framework/views
public/build

A good .dockerignore can make builds faster before you touch Buildx, cloud builders, or CI caching.

4. Use Buildx cache for faster local and CI builds

Keyword targets: docker buildx, docker build cache, docker ci cd

Build cache is one of those things people ignore until CI takes 15 minutes. Then everyone suddenly cares.

A useful registry cache setup looks like this:

docker buildx build \
  --cache-from type=registry,ref=ghcr.io/acme/my-app:buildcache \
  --cache-to type=registry,ref=ghcr.io/acme/my-app:buildcache,mode=max \
  -t ghcr.io/acme/my-app:latest \
  --push .

For GitHub Actions, the cache backend can be simpler:

docker buildx build \
  --cache-from type=gha \
  --cache-to type=gha,mode=max \
  -t my-app:ci .

The important part is not the exact command. The important part is that your CI should not rebuild the world every time someone changes one line of code.

5. Use Docker Build Cloud when builds are too slow locally

Keyword targets: docker build cloud, faster docker builds, docker multi architecture build

Local builds are fine until they are not. Large monorepos, multi-architecture images, and heavy dependency installs can make laptops miserable.

Docker Build Cloud moves the build work to cloud builders and gives teams shared cache. That is especially useful when several developers or CI jobs build the same project all day.

Use Build Cloud when:

  • You build for both linux/amd64 and linux/arm64
  • CI runners are slow or underpowered
  • Developers keep waiting on the same dependency layers
  • Builds are blocking pull request feedback

A multi-platform build usually looks like this:

docker buildx build \
  --platform linux/amd64,linux/arm64 \
  -t ghcr.io/acme/my-app:1.0.0 \
  --push .

The trick is to stop treating build speed as a local machine problem. Once the team grows, build time becomes a workflow problem.

6. Scan images with Docker Scout before pushing

Keyword targets: docker scout, docker image security, docker vulnerability scan

Docker Scout gives you a quick look at vulnerabilities in an image and its base image. It is not a replacement for security review, but it is a good early warning system.

Start with:

docker scout quickview my-app:latest

Then check CVEs:

docker scout cves my-app:latest

For base image suggestions:

docker scout recommendations my-app:latest

A sensible local flow:

docker build -t my-app:local .
docker scout quickview my-app:local
docker scout cves my-app:local

Do this before pushing to a registry. Finding a bad base image after deploy is annoying. Finding it before push is just part of the build.

7. Start from smaller and safer base images

Keyword targets: docker hardened images, secure docker images, minimal docker images

Base images matter. A bloated base image gives you more packages, more CVEs, and more things you did not mean to ship.

For small apps, start with slim images:

FROM python:3.13-slim

Or:

FROM node:22-bookworm-slim

For stricter production environments, look at Docker Hardened Images. They are designed as minimal, production-ready images with a stronger security baseline.

A safe migration plan:

  1. Scan your current image.
  2. Replace the base image in a separate branch.
  3. Run unit tests and integration tests.
  4. Compare image size and vulnerability results.
  5. Deploy to staging before production.

Do not swap base images blindly. A smaller image is nice. A working image is better.

8. Run containers as a non-root user

Keyword targets: docker non root user, docker security best practices, docker container security

A container is not a magic security wall. If your app does not need root, do not run it as root.

For Node.js, the official image already includes a node user:

FROM node:22-bookworm-slim

WORKDIR /app

COPY package*.json ./
RUN npm ci --omit=dev

COPY . .

USER node

CMD ["node", "server.js"]

For Python, create a user:

FROM python:3.13-slim

WORKDIR /app

RUN useradd --create-home --shell /usr/sbin/nologin appuser

COPY requirements.txt .
RUN pip install --no-cache-dir -r requirements.txt

COPY . .

USER appuser

CMD ["python", "app.py"]

You will sometimes hit file permission issues after switching users. That is normal. Fix the ownership of the app directory instead of going back to root. If bind mounts or volume permissions keep fighting you, Arch Linux: setting ACLs for proper file permissions walks through a fix that also applies inside containers:

COPY --chown=appuser:appuser . .

9. Stop putting secrets directly in Compose files

Keyword targets: docker compose secrets, docker environment variables, docker production security

This is bad:

services:
  api:
    image: my-api
    environment:
      DATABASE_PASSWORD: "super-secret-password"

Use secrets instead:

services:
  api:
    image: my-api
    environment:
      DATABASE_USER: app
      DATABASE_NAME: appdb
    secrets:
      - db_password

secrets:
  db_password:
    file: ./secrets/db_password.txt

Inside the container, Docker makes the secret available as a file:

/run/secrets/db_password

Your app can read it at startup.

This does not solve every secret management problem, but it is better than leaving passwords in compose.yaml, shell history, screenshots, and Git commits. Pair Compose secrets with boot-time validation so missing keys fail loudly — see Type-safe environment configuration for Next.js or EnvValidator for Laravel & PHP.

10. Use labels so images explain themselves

Keyword targets: docker labels, docker image metadata, oci image labels

When you have many images, names and tags are not enough. Add OCI labels so the image tells you where it came from.

LABEL org.opencontainers.image.title="my-app"
LABEL org.opencontainers.image.description="API service for the customer dashboard"
LABEL org.opencontainers.image.source="https://github.com/acme/my-app"
LABEL org.opencontainers.image.version="1.0.0"
LABEL org.opencontainers.image.licenses="MIT"

Then inspect labels:

docker image inspect my-app:latest

This is small, but it helps later when someone asks, “Which repo built this image?”

That person might be you in three months.

11. Use Compose profiles for optional services

Keyword targets: docker compose profiles, docker compose development, docker local dev

Not every developer needs every service running all the time. Search, mail testing, queues, workers, and admin tools can be optional.

services:
  app:
    build: .
    ports:
      - "3000:3000"

  postgres:
    image: postgres:17
    environment:
      POSTGRES_PASSWORD: postgres

  mailpit:
    image: axllent/mailpit
    ports:
      - "8025:8025"
    profiles:
      - tools

  redis:
    image: redis:7
    profiles:
      - cache

Run the normal stack:

docker compose up

Run it with tools:

docker compose --profile tools up

Run it with cache too:

docker compose --profile tools --profile cache up

Profiles keep your default local setup lighter without deleting useful services.

12. Debug Docker problems with Gordon

Keyword targets: docker gordon, docker ai agent, docker container debugging

Gordon is Docker’s AI agent for Docker workflows. In 2026, this is one of the most interesting Docker changes because it is not just “ask a chatbot a question.” Gordon can understand your Docker environment and suggest actions, with your approval.

Good use cases:

  • A Compose service exits immediately
  • A port is already taken
  • A Dockerfile builds slowly
  • A container cannot connect to another service
  • An image is larger than expected
  • Logs show an error you do not recognize

Example prompts you can try:

Why is my web container exiting after startup?
Check my Dockerfile and suggest ways to reduce image size.
Look at my Compose file and explain why the API cannot reach Postgres.
Find unused containers, images, and volumes I can safely remove.

Do not approve commands without reading them. Treat Gordon like a junior teammate who can inspect the project quickly but still needs review.

13. Run local AI models with Docker Model Runner

Keyword targets: docker model runner, run llm with docker, docker local ai

Docker Model Runner lets you run and manage AI models locally with Docker. That means you can test AI features without wiring everything to a paid API on day one.

Check whether it is available:

docker model version

Pull a small model:

docker model pull ai/smollm2:360M-Q4_K_M

Run it:

docker model run ai/smollm2

This is useful for:

  • Testing prompt flows locally
  • Building a prototype chatbot
  • Running small models for private development
  • Checking AI features without sending every request to a cloud provider

Local models are not automatically better than API models. They can be slower, smaller, and less capable. But they are useful when privacy, cost, or offline development matters.

14. Define AI models inside Docker Compose

Keyword targets: docker compose ai, docker compose models, docker model runner compose

Docker Compose now supports defining AI models as part of an application. That makes AI dependencies visible beside the app, database, cache, and worker.

A minimal example:

services:
  chat-app:
    build: .
    ports:
      - "3000:3000"
    models:
      llm:
        endpoint_var: AI_MODEL_URL
        model_var: AI_MODEL_NAME

models:
  llm:
    model: ai/smollm2
    context_size: 4096

Your app can read:

AI_MODEL_URL
AI_MODEL_NAME

This is cleaner than hiding the model setup in a README that nobody reads.

Use this pattern when your application depends on a model the same way it depends on Postgres or Redis.

15. Use Docker MCP Toolkit for AI tools

Keyword targets: docker mcp toolkit, docker mcp catalog, docker mcp gateway

MCP servers let AI clients connect to tools and data sources. The messy part is installing and running those servers safely. Docker MCP Toolkit helps by running MCP servers through Docker and connecting them to clients such as editors or AI tools.

A manual MCP Gateway config can look like this:

{
  "servers": {
    "MCP_DOCKER": {
      "command": "docker",
      "args": ["mcp", "gateway", "run", "--profile", "my_profile"],
      "type": "stdio"
    }
  }
}

Use MCP profiles for different work:

frontend-dev
backend-dev
data-tools
github-tools
docs-tools

Keep the profiles small. Giving an AI agent every possible tool is a bad habit. Give it the tools it needs for the task. For a self-hosted agent outside Docker’s MCP stack, What is OpenClaw? covers another local-first approach to agent workflows and tool access.

16. Clean up Docker safely

Keyword targets: docker cleanup, docker prune, docker system df

Docker can eat disk space quietly. The commands below handle day-to-day cleanup. When prune is not enough, How to factory-reset Docker walks through a full reset on Linux, macOS, and Windows.

Before deleting things, check what is using space:

docker system df

Remove stopped containers:

docker container prune

Remove dangling images:

docker image prune

Remove unused networks:

docker network prune

Be careful with this one:

docker system prune -a

It removes more than people expect. Do not run it on a machine where you are not sure what needs to stay.

For volumes, check before deleting:

docker volume ls
docker volume inspect volume_name

Then remove only what you know is safe:

docker volume rm volume_name

A deleted database volume is not a cleanup. It is a bad afternoon.

17. Use healthchecks for real startup status

Keyword targets: docker healthcheck, docker compose depends_on, docker container health

A container can be “running” while the app inside it is still broken. Add a healthcheck when other services depend on it.

services:
  api:
    build: .
    ports:
      - "3000:3000"
    healthcheck:
      test: ["CMD", "curl", "-f", "http://localhost:3000/health"]
      interval: 10s
      timeout: 3s
      retries: 5
      start_period: 20s

For Postgres:

services:
  postgres:
    image: postgres:17
    environment:
      POSTGRES_PASSWORD: postgres
    healthcheck:
      test: ["CMD-SHELL", "pg_isready -U postgres"]
      interval: 10s
      timeout: 5s
      retries: 5

Then your app can wait for the database:

services:
  api:
    build: .
    depends_on:
      postgres:
        condition: service_healthy

  postgres:
    image: postgres:17
    environment:
      POSTGRES_PASSWORD: postgres
    healthcheck:
      test: ["CMD-SHELL", "pg_isready -U postgres"]
      interval: 10s
      timeout: 5s
      retries: 5

This avoids a common local bug: the app starts faster than the database and crashes on boot.

18. Pin versions, but do not forget updates

Keyword targets: docker image tags, docker best practices, docker security updates

This is risky:

FROM node:latest

Use a real version:

FROM node:22-bookworm-slim

For stricter production builds, pin by digest:

FROM node:22-bookworm-slim@sha256:your_digest_here

Pinning gives you repeatable builds. It also means you must update intentionally. A pinned image does not magically receive security fixes in your already built image. Rebuild and rescan regularly.

A good production rhythm:

  • Pin the base image version.
  • Rebuild images on a schedule.
  • Run Docker Scout or another scanner.
  • Update base images after testing.
  • Keep a changelog for image changes.

Repeatable builds are good. Forgotten builds are not.

19. Build images with SBOM and provenance when needed

Keyword targets: docker sbom, docker provenance, docker supply chain security

For teams that care about supply chain security, Buildx can generate attestations during build.

docker buildx build \
  --sbom=true \
  --provenance=true \
  -t ghcr.io/acme/my-app:1.0.0 \
  --push .

This is useful when you need a clearer record of what went into an image and how it was built.

Not every small side project needs full supply chain metadata. A production app, especially one used by clients or deployed in regulated environments, probably does.

20. Use a simple production checklist

Keyword targets: docker production checklist, docker container best practices, docker deployment best practices

Before pushing a Docker image to production, check these:

  • The image uses a specific base version, not latest.
  • The final image does not include dev dependencies.
  • The app runs as a non-root user.
  • Secrets are not stored in the image or Compose file.
  • .dockerignore removes local junk from the build context.
  • The image has been scanned.
  • Healthchecks exist for services that need them.
  • Logs go to stdout and stderr.
  • The image can be rebuilt from source.
  • The team knows how to update the base image.

That checklist catches boring mistakes. Boring mistakes are the expensive ones.

Best keywords to target for this article

Primary keyword:

docker tricks 2026

Secondary keywords:

docker tips and tricks
docker best practices
docker compose watch
dockerfile best practices
docker buildx cache
docker scout
docker hardened images
docker model runner
docker mcp toolkit
docker gordon
docker ai agent

Long-tail keywords:

how to make docker builds faster
how to reduce docker image size
how to secure docker containers
how to use docker compose watch
how to scan docker images with docker scout
how to run local ai models with docker
how to use docker mcp toolkit
docker production best practices 2026

FAQ

Is Docker still worth learning in 2026?

Yes. Docker is still one of the most useful tools for local development, CI pipelines, container deployment, testing, and software supply chain work. The newer AI features make Docker even more relevant for developers building AI-assisted apps and agent workflows.

What is the best Docker trick for faster development?

Use Docker Compose Watch. It can sync source files, rebuild when dependency files change, and restart services when config files change. For many teams, this removes the slow edit-build-run cycle.

How do I make Docker builds faster?

Start with a .dockerignore file, copy dependency files before copying the full source, use multi-stage builds, and configure Buildx cache in CI. If builds are still slow, look at Docker Build Cloud or another remote builder.

How do I reduce Docker image size?

Use a slim base image, multi-stage builds, and production-only dependencies. Do not copy tests, local caches, source maps, package manager caches, or build tools into the final runtime image unless the app truly needs them.

How do I secure Docker images?

Use trusted base images, pin versions, scan with Docker Scout, run as a non-root user, avoid storing secrets in images, and rebuild images regularly. For production, consider Docker Hardened Images or another hardened base image strategy.

Can Docker run AI models locally?

Yes. Docker Model Runner can pull, run, and serve local AI models. You can also define model dependencies in Docker Compose so the model becomes part of your app stack.

What is Docker MCP Toolkit used for?

Docker MCP Toolkit helps run and manage MCP servers for AI tools. It is useful when you want AI clients to access tools through containerized MCP servers instead of installing everything directly on your machine.

Final thoughts

Docker in 2026 is not just about containers anymore. The basics still matter, but the real value is in the workflow around the container.

Use Compose Watch so development feels fast. Use Buildx cache so CI stops wasting time. Use Scout and hardened base images so security checks happen before production. Try Gordon when Docker errors get messy. Try Model Runner and MCP Toolkit when your app starts touching AI.

The best Docker setup is not the most complex one. It is the one your team can understand, rebuild, scan, and ship without guessing. For a full production Compose stack — MySQL, Nginx, SSL, and backups — see Deploy WordPress with Docker.

Useful Docker references