Docker en 2026: Compose v5, MCP Toolkit, Model Runner y todo lo que ha cambiado

Docker cumplió en 2024 diez años siendo la herramienta estándar para contenedores en desarrollo. En 2026, la historia no es solo contenedores: Docker se está convirtiendo en la plataforma donde se despliegan y orquestan stacks de IA, servidores MCP y modelos locales. Docker Compose v5, lanzado con la especificación Mont Blanc en diciembre de 2025, el MCP Toolkit integrado en Docker Desktop, el Model Runner para ejecutar LLMs localmente y Docker Engine 29 son los cambios más relevantes de los últimos meses.

Esta guía cubre lo que realmente ha cambiado y cómo afecta al trabajo diario de un desarrollador que usa Docker en proyectos web y de IA.

Docker Compose v5: lo que cambia de verdad

Docker Compose v5 (especificación Mont Blanc, diciembre 2025) trae tres cambios arquitecturales importantes.

El builder interno desaparece: Docker Bake toma el control

El cambio más técnico es que Compose v5 elimina su builder interno y delega todos los builds a Docker Bake. Esto significa builds más rápidos con mejor caché, soporte nativo para builds multi-plataforma (AMD64 + ARM64 en un solo comando) y acceso a todas las features avanzadas de BuildKit.

# compose.yaml — v5 con watch mode y build mejorado
services:
  web:
    build:
      context: .
      dockerfile: Dockerfile
      platforms:
        - linux/amd64
        - linux/arm64
    develop:
      watch:
        - action: sync
          path: ./src
          target: /app/src
        - action: rebuild
          path: package.json

El modo watch con sync es especialmente útil: sincroniza los cambios de archivos en tiempo real sin reconstruir el contenedor, y solo hace rebuild cuando cambia algo que realmente lo requiere (como package.json).

Go SDK oficial: Compose como librería

Compose v5 incluye un Go SDK oficial que permite integrar la funcionalidad de Compose directamente en aplicaciones Go sin depender del CLI:

// Ejemplo: integrar Compose en una herramienta de CI propia
package main

import (
    "context"
    "github.com/compose-spec/compose-go/v2/compose"
)

func main() {
    ctx := context.Background()

    // Cargar y validar el compose.yaml
    project, err := compose.Load(ctx, compose.Options{
        WorkingDir: "./mi-proyecto",
        ConfigPaths: []string{"compose.yaml"},
    })
    if err != nil {
        panic(err)
    }

    // Levantar los servicios programáticamente
    err = compose.Up(ctx, project, compose.UpOptions{
        Detach: true,
    })
}

Esto es especialmente útil para herramientas de DevOps internas que necesitan gestionar stacks de Compose sin hacer shell out al CLI.

Sintaxis actualizada: compose.yaml en lugar de docker-compose.yml

Aunque ambos nombres siguen siendo válidos, la convención oficial en 2026 es compose.yaml (sin el prefijo docker- y con extensión .yaml). Compose v5 busca en este orden: compose.yaml, compose.yml, docker-compose.yaml, docker-compose.yml.

# Comandos actualizados en Compose v5
docker compose up -d          # Levantar en background
docker compose watch          # Hot reload en desarrollo
docker compose down -v        # Bajar y eliminar volúmenes
docker compose logs -f web    # Seguir logs de un servicio
docker compose ps             # Estado de los servicios
docker compose exec web sh    # Shell en un contenedor

# NUNCA usar el comando antiguo con guión
# docker-compose está completamente deprecado desde 2024

Docker para proyectos web: el stack completo

# compose.yaml — stack web en producción con Next.js + Supabase local
services:
  web:
    build:
      context: .
      target: production  # Multi-stage build
    ports:
      - "3000:3000"
    environment:
      - NODE_ENV=production
      - NEXT_PUBLIC_SUPABASE_URL=http://kong:8000
    depends_on:
      supabase-db:
        condition: service_healthy
    restart: unless-stopped

  supabase-db:
    image: supabase/postgres:15.1.0.147
    volumes:
      - postgres_data:/var/lib/postgresql/data
      - ./supabase/seed.sql:/docker-entrypoint-initdb.d/seed.sql
    environment:
      POSTGRES_PASSWORD: ${DB_PASSWORD}
    healthcheck:
      test: ["CMD-SHELL", "pg_isready -U postgres"]
      interval: 10s
      timeout: 5s
      retries: 5
    restart: unless-stopped

  nginx:
    image: nginx:alpine
    ports:
      - "80:80"
      - "443:443"
    volumes:
      - ./nginx.conf:/etc/nginx/nginx.conf:ro
      - ./certs:/etc/nginx/certs:ro
    depends_on:
      - web
    restart: unless-stopped

volumes:
  postgres_data:

networks:
  default:
    driver: bridge

Docker MCP Toolkit: contenedores para servidores MCP

Una de las novedades más relevantes de Docker Desktop en 2026 es el MCP Toolkit: una forma de levantar servidores MCP como contenedores, con catálogo de servidores verificados directamente en Docker Hub.

La idea es simple: en lugar de instalar y configurar servidores MCP de forma manual, los levantas como contenedores con Docker Compose:

# compose.yaml — stack con servidores MCP para desarrollo IA
services:
  mcp-github:
    image: mcp/github:latest
    environment:
      - GITHUB_TOKEN=${GITHUB_TOKEN}
    ports:
      - "3100:3100"

  mcp-postgres:
    image: mcp/postgres:latest
    environment:
      - DATABASE_URL=postgresql://postgres:password@db:5432/mydb
    depends_on:
      - db
    ports:
      - "3101:3101"

  mcp-filesystem:
    image: mcp/filesystem:latest
    volumes:
      - ./proyecto:/workspace:ro  # Solo lectura por seguridad
    ports:
      - "3102:3102"

Desde Claude Desktop o Cursor, apuntas a estos servidores MCP locales y el agente tiene acceso a GitHub, tu base de datos y tu sistema de archivos, todo corriendo en contenedores aislados con los permisos que tú defines.

Docker Model Runner: LLMs locales sin configuración

Docker Model Runner permite ejecutar modelos de lenguaje localmente con una API compatible con OpenAI, sin configurar Ollama ni gestionar dependencias de GPU manualmente:

# Descargar y ejecutar un modelo
docker model pull llama3.2:3b
docker model run llama3.2:3b

# Listar modelos disponibles
docker model list

# La API está disponible en localhost:12434
curl http://localhost:12434/v1/chat/completions \
  -H "Content-Type: application/json" \
  -d '{
    "model": "llama3.2:3b",
    "messages": [{"role": "user", "content": "Hola, ¿cómo estás?"}]
  }'

En Compose, puedes integrarlo directamente en el stack:

services:
  llm:
    provider:
      type: model
      options:
        model: llama3.2:3b
        embeddings: true  # Activar soporte para embeddings

  mi-app:
    build: .
    environment:
      - LLM_URL=http://model-runner.docker.internal:12434
    depends_on:
      - llm

Dockerfile multi-stage: el patrón que más impacto tiene

El Dockerfile multi-stage sigue siendo el patrón con mayor retorno en cualquier proyecto que use Docker. Reduce el tamaño de la imagen de producción drásticamente:

# Dockerfile — multi-stage para Next.js
FROM node:20-alpine AS base
WORKDIR /app
COPY package*.json ./

# Etapa de dependencias
FROM base AS deps
RUN npm ci --frozen-lockfile

# Etapa de build
FROM base AS builder
COPY --from=deps /app/node_modules ./node_modules
COPY . .
RUN npm run build

# Etapa de producción — solo lo necesario
FROM node:20-alpine AS production
WORKDIR /app
ENV NODE_ENV=production

# Copiar solo los artefactos necesarios
COPY --from=builder /app/.next/standalone ./
COPY --from=builder /app/.next/static ./.next/static
COPY --from=builder /app/public ./public

# Usuario no root por seguridad
RUN addgroup -g 1001 -S nodejs && adduser -S nextjs -u 1001
USER nextjs

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

Esta configuración produce una imagen de producción de ~150MB frente a los 2-3GB de una imagen sin optimizar.

Errores comunes en 2026

Seguir usando `docker-compose` con guión. Está completamente deprecado. Todos los entornos modernos (GitHub Actions, Vercel, CI en general) ya usan docker compose con espacio. Actualiza tus scripts y documentación.

No usar health checks. El depends_on sin condición de health check no garantiza que el servicio dependiente esté realmente listo. Siempre añade health checks y usa condition: service_healthy.

Secrets en variables de entorno en el compose.yaml. Las contraseñas y API keys en environment: en el compose.yaml se exponen en el historial de Docker y en docker inspect. Usa secrets: de Compose o variables de entorno del host con .env:

# Mal — expone el secreto
services:
  db:
    environment:
      - POSTGRES_PASSWORD=mi-password-secreta

# Bien — usa el fichero .env que está en .gitignore
services:
  db:
    environment:
      - POSTGRES_PASSWORD=${DB_PASSWORD}  # Viene del .env

Volúmenes sin nombre para datos persistentes. Los volúmenes anónimos se eliminan con docker compose down -v. Los volúmenes con nombre persisten. Para datos de base de datos, siempre usa volúmenes con nombre.

Conclusión

Docker en 2026 no es solo la herramienta para "que funcione en cualquier máquina". Es la plataforma donde corre el stack completo: tu aplicación, tu base de datos, tus servidores MCP y tus modelos de IA locales. Docker Compose v5 con su nuevo Go SDK y la delegación a Docker Bake hace los builds más eficientes. El MCP Toolkit simplifica la gestión de servidores de IA. Y el Model Runner democratiza el uso de LLMs locales sin conocimientos de infraestructura de ML.

Si tienes proyectos que todavía usan docker-compose con guión o que no tienen multi-stage builds, esos son los dos cambios que más retorno te van a dar con menos esfuerzo.