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.