Beyond Containers: Docker’s Evolution into an AI Development Platform

Gordon, Model Runner, Bake GA, MCP Toolkit, Docker Sandboxes, Hardened Images — a precise, fact-checked guide to every major Docker feature from early 2024 to mid-2026.

If you last seriously looked at Docker in 2023, you’re in for a surprise.

For years, Docker’s story was straightforward: package your app, ship it anywhere, run it the same way everywhere. Containers. Images. Registries. That story hasn’t changed, but it has been dramatically extended.

Friend link for non-Medium members: Beyond Containers: Docker’s Evolution into an AI Development Platform

If you enjoy content like this, feel free to connect with me on X (@PrateekJainDev) and LinkedIn (in/prateekjaindev)

Between early 2024 and May 2026, Docker shipped more transformative features than in the preceding three years combined. The headline? Docker is now an AI development platform. An embedded AI assistant can explain and fix your Dockerfiles. You can run large language models locally with a single command. You can wire up 100+ MCP servers to your AI coding tools from a graphical catalogue. And all of this ships inside the same Docker Desktop you’ve always used.

The AI Revolution: Gordon, Model Runner, MCP Toolkit & Sandboxes

This is the biggest story in Docker’s recent history, and it unfolded in layers across 2025 and into 2026.

Docker AI Agent: Gordon

Gordon is Docker’s embedded AI assistant, and it is deeply integrated, not bolted on. It debuted in beta with Docker Desktop in February 2025 and reached general availability in May 2026.

What makes Gordon different from dropping a question into a chat window is context. Gordon knows your local environment: your running containers, your Compose stacks, your Dockerfiles, your build failures. When a docker build or docker run fails, Gordon surfaces contextual hints inline, you don't have to copy-paste error messages anywhere.

What Gordon can do:

• Explain a Dockerfile line-by-line and rate it for correctness, security, and best practices
• Suggest optimised rewrites — multi-stage builds, layer caching improvements, base image recommendations
• Propose docker run commands with flags calibrated to your local context
• Diagnose and fix failing containers
• Retain memory of your preferences and past sessions
• Respond to failures in docker build, docker run, and docker compose with inline suggestions

Docker Model Runner (DMR)

Docker Model Runner is exactly what it sounds like: a way to run LLMs locally, managed like any other Docker resource, exposed via an OpenAI-compatible API.

It launched in beta in April 2025 exclusively for Mac Apple Silicon, and expanded rapidly:

Under the hood, Model Runner is built on llama.cpp (and later vLLM for higher-throughput inference). Models are packaged as OCI Artefacts, meaning you can pull, push, and distribute them through any OCI-compatible registry — including Docker Hub.

Key CLI commands:

# Pull and run a model
docker model pull ai/qwen3.5
docker model run ai/llama3

# Inspect what's happening under the hood
docker model requests       # See prompts and responses in real time (4.47+)
# Tune context window
docker model configure --context-size 8192
# Clean up downloaded models
docker model purge

Supported models include Qwen3.5, Llama, Gemma, EmbeddingGemma, and more, and you can push custom fine-tuned models to a registry and share them across teams exactly as you would a container image.

The OpenAI-compatible API endpoint means any tool that speaks OpenAI’s format can point at Model Runner with zero code changes.

Docker MCP Toolkit & Catalog

The Model Context Protocol (MCP) has become the de facto standard for connecting AI agents to external tools and data sources. Docker saw this early and built first-class support directly into Docker Desktop.

The result is an MCP catalogue with 100+ pre-built servers covering everything from GitHub to Slack to databases to web search. Each MCP server in Docker’s catalogue ships as a signed OCI artefact, meaning Docker handles the security surface for you, no random Node scripts running on your machine.

The toolkit works out of the box with Claude Desktop, Cursor, Continue.dev, VS Code, Gemini CLI, and Goose. You select the servers you want, Docker manages the runtime, and your AI tool sees a clean set of capabilities.

Docker Sandboxes

Sandboxes are microVM-based execution environments designed specifically for AI coding agents. When an agent needs to execute code, run tests, or interact with a filesystem, a Sandbox gives it an isolated, disposable environment that’s significantly more secure than a plain container, without the weight of a full VM.

This is especially relevant as agentic workflows become more common. If you’re using Gordon or another coding agent that executes commands autonomously, Sandboxes are the runtime layer that keeps that execution contained.

Docker AI Governance (May 2026)

With AI agents now capable of executing code, making network calls, and accessing credentials, Docker introduced a centralised governance layer in May 2026. Administrators can define:

• Which MCP tools can individual developers or teams use
• What network access agent workloads are permitted
• Which credentials are available to agent runtimes

This matters for teams in regulated environments or anyone who needs audit trails for what their AI tooling actually did.

Build Smarter: Bake GA, BuildKit Enhancements & Hardened Images

Docker Bake Goes GA

docker buildx bake reached general availability in February 2025. If you're not familiar with Bake, think of it as Makefile meets Terraform for Docker builds, a declarative HCL or JSON file that describes all your build targets, their relationships, caching strategies, and build arguments.

Why Bake matters:

Before Bake, building a monorepo with multiple services meant either shell scripts with ordered docker build calls or CI pipelines that reinvented the wheel. Bake formalises all of that:

# docker-bake.hcl
variable "TAG" {
  default = "latest"
  validation = regex("^[a-z0-9-]+$", TAG)
}

target "api" {
  context = "./services/api"
  tags    = ["myregistry/api:${TAG}"]
  cache-from = ["type=registry,ref=myregistry/api:cache"]
  cache-to   = ["type=registry,ref=myregistry/api:cache,mode=max"]
}

target "worker" {
  context = "./services/worker"
  tags    = ["myregistry/worker:${TAG}"]
  inherits = ["api"]   # Share provenance and cache settings
}

# Build everything
docker buildx bake

# See what would be built
docker buildx bake --list targets

# Build a specific target
docker buildx bake api

# Matrix builds
docker buildx bake --set "*.platform=linux/amd64,linux/arm64"

GA features include:

• Deduplicated context transfers (shared layers between targets are only sent once)
• Variable validation (Terraform-style)
• Composable attributes, provenance and cache as structured objects you can inherit
• --list targets and --list variables with JSON output for CI integration
• Entitlements: --allow network.host, --allow fs=..., --allow ssh

BuildKit Enhancements

BuildKit v0.30.0 shipped with Engine 29.5 and brought several quality-of-life improvements that land quietly but save real time:

# Exclude specific paths during COPY (no more .dockerignore gymnastics)
COPY --exclude=tests --exclude=docs . /app

# Combine unpack and chown in a single ADD
ADD --unpack --chown=app:app app.tar.gz /app

# Add Git repos with query parameters
ADD git://github.com/org/repo.git?ref=v1.2.3 /vendor/repo

The Builds view in Docker Desktop now displays SLSA v1 provenance metadata, so you can inspect the full build chain for any image directly from the UI, useful for supply chain compliance.

Docker Hardened Images (DHI)

DHI is Docker’s offering in the distroless/minimal image space, with added guarantees around signing and supply chain integrity. These are production-grade base images designed to minimise attack surface, no shell, no package manager, no unnecessary binaries.

The docker dhi CLI plugin landed in Desktop 4.65 (with dhictl v0.0.3 bundled in 4.72), giving you a dedicated workflow for managing hardened image subscriptions and versions.

# List available hardened images
docker dhi list

# Pull a specific hardened image
docker dhi pull docker.io/docker/hardened-node:20
# Check image metadata
docker dhi inspect docker.io/docker/hardened-python:3.12

Compose Reimagined: Watch GA, v5 SDK & Compose Bridge

docker compose watch Goes GA

compose watch solves one of the most persistent friction points in container-based development: keeping your running containers in sync with your source code changes without constantly restarting them.

# compose.yaml
services:
  api:
    build: .
    develop:
      watch:
        - action: sync
          path: ./src
          target: /app/src
        - action: rebuild
          path: ./package.json
        - action: sync+restart
          path: ./config
          target: /app/config
      initial_sync: true   # Sync on first start (2025+)

# Start with file watching
docker compose watch

# Watch and prune stale files on the target
docker compose watch --prune

The three action types give you a spectrum of responses: sync for fast hot-reload scenarios (static assets, interpreted languages), sync+restart when the process needs to restart but not rebuild, and rebuild for changes that require a new image layer. This eliminates most of the custom scripting teams built around nodemon, air, or similar tools inside containers.

Compose v5.0 “Mont Blanc”

This is the biggest Compose release since v2. The version jumped straight from 2.x to 5.0, intentionally skipping 3.x and 4.x to avoid confusion with legacy Compose file format version numbers.

The headline: Compose is now a Go SDK.

Previously, Compose was a CLI tool you could only invoke as a subprocess. With v5, the Compose engine is a proper Go library. Third-party tools — orchestrators, platform tools, custom CLIs — can embed Compose orchestration directly without shelling out to docker compose up.

Other major additions:

# Wait for services to be healthy before returning
docker compose start --wait

# Skip the registry for testing (useful in air-gapped CI)
docker compose build --insecure-registry

New Compose file features:

# Declare AI model dependencies declaratively
models:
  llm:
    model: ai/llama3
    options:
      context_size: 4096
services:
  app:
    build: .
    environment:
      - MODEL_URL=http://model-runner/v1
# Mount an image as a volume (no extraction step)
volumes:
  assets:
    driver: local
    driver_opts:
      type: image
      device: myregistry/assets:latest
# Multi-file composition
include:
  - path: ./infra/compose.yaml
  - path: ./monitoring/compose.yaml

The internal builder was removed in v5 — all image builds are now delegated to docker buildx / Bake. This gives Compose builds all the benefits of BuildKit by default.

Compose Bridge

Compose Bridge converts compose.yaml files into Kubernetes manifests. If you're developing locally with Compose and deploying to Kubernetes, Bridge eliminates the manual translation step:

# Generate Kubernetes manifests from your compose file
docker compose bridge --output ./k8s-manifests

# Target a specific Kubernetes flavor
docker compose bridge --flavor helm --output ./chart

This is particularly useful for teams who want to keep Compose as the developer-facing API while deploying to Kubernetes in production, a very common pattern that previously required maintaining two separate configuration sets.

CLI Power-Ups

Docker’s CLI gained a wave of new top-level commands over this period. Here’s a practical guide to each.

docker init

# Interactive scaffolding for any project
docker init

Running docker init in a project directory, analyses your codebase, detects the language and framework, and generates a Dockerfile, compose.yaml, and .dockerignore tuned to your project. It's the fastest path from a bare repo to a working containerised setup.

docker debug

# Shell into a running container (even one with no shell)
docker debug my-container

# Debug a stopped container
docker debug --image busybox my-stopped-container
# Debug directly from an image (no container needed)
docker debug my-image:latest

docker debug attaches a shell to any container or image, including distroless images with no shell at all, by injecting a toolbox image. It was originally a paid feature but became free for all users. This is the end of docker exec /bin/sh not found frustration.

docker desktop

docker desktop became GA in Desktop 4.40, giving you full programmatic control over Docker Desktop:

docker desktop start
docker desktop stop
docker desktop status
docker desktop logs

# Enable Model Runner with GPU and CORS
docker desktop enable model-runner --gpu --cors
# Manage Kubernetes
docker desktop kubernetes enable
docker desktop kubernetes disable
# Diagnostics
docker desktop diagnose    # Added in 4.60

This is especially useful in CI environments where Docker Desktop is the runtime, and you need to manage its lifecycle from scripts.

docker scout

# Analyze an image for CVEs
docker scout cves myimage:latest

# Generate a Software Bill of Materials
docker scout sbom myimage:latest

# Compare two images
docker scout compare myimage:v1 myimage:v2

# Get recommendations
docker scout recommendations myimage:latest

Scout expanded significantly through 2024–2025, adding SBOM generation, policy evaluation, and registry-side analysis so you can catch vulnerabilities before images reach production.

Cloud & Scale: Docker Offload & Cloud Contexts

Docker Offload

Docker Offload lets you push resource-intensive builds and container runs to Docker’s cloud infrastructure instead of your local machine. It launched in beta with Desktop 4.45 and expanded through 4.74.

# Offload a build to Docker Cloud
docker offload build -t myimage:latest .

# Run a container in Docker Cloud
docker offload run --rm myimage:latest

# Check offload status
docker offload status

When Offload makes sense:

• Building ARM images on an x86 machine (or vice versa) — no QEMU emulation slowness
• GPU workloads when you don’t have local GPU access
• Heavy builds that would thermal-throttle a laptop
• Keeping the local machine responsive during long builds

Cloud contexts integrate with your Docker Desktop sign-in, so there’s no separate authentication setup.

docker buildx prune Storage Management

Bake and BuildKit produce aggressive cache that can fill disks quickly. Engine 28+ added fine-grained cache management:

# Keep at least 20GB free on the build cache volume
docker buildx prune --min-free-space 20GB

# Never let cache exceed 50GB
docker buildx prune --max-used-space 50GB

# Always reserve 10GB for new builds
docker buildx prune --reserved-space 10GB

These options let you set policies rather than manually clearing cache — set them in CI or on developer machines and forget about disk pressure.

What to Watch

• Gordon GA maturation — higher usage limits, more context sources, team-shared memory
• Model Runner on more platforms — the Linux story via WSL2/vLLM is still relatively new
• Compose SDK adoption — third-party tools embedding Compose will become common
• MCP ecosystem growth — 100+ servers today; expect ecosystem tooling to explode
• Hardened Images expansion — more base images, more language runtimes
• AI Governance controls — policy-as-code for agent execution

Conclusion

Docker in 2026 is a genuinely different product from Docker in 2023, not because it abandoned what made it great, but because it extended those fundamentals into new territory.

The container model, declarative, portable, reproducible, turned out to be exactly the right abstraction for AI models too. docker model pull is conceptually identical to docker image pull. MCP servers are just another kind of service. Sandboxes are just containers with stronger isolation guarantees. The mental model transfers.

If there’s one theme across all of this, it’s that Docker kept asking: what if this new thing was just another Docker resource? LLMs, AI agents, MCP servers, hardened images, cloud build capacity, they all got the same treatment: OCI artefacts, CLI commands, Compose integration, Desktop UI.

That consistency is what makes the last two years of Docker development feel coherent rather than scattered. They’re not chasing trends. They’re extending a platform.

You can follow me on X (@PrateekJainDev) and LinkedIn (in/prateekjaindev) for more such posts!