Docker Swarm en 2023: cuando sigue teniendo sentido

Actualizado: 2026-05-03

La narrativa popular dice que Kubernetes ganó y Docker Swarm está muerto. La realidad es más matizada. Swarm sigue siendo mantenido como parte de Docker Engine, funciona perfectamente en producción y para una franja específica de casos sigue siendo la opción correcta — no una opción legacy. Esta guía cubre cuándo Swarm tiene sentido, qué cuesta menos operar y qué limitaciones aceptas a cambio.

Puntos clave

• Swarm está integrado en Docker Engine y recibe mantenimiento regular; no es un proyecto abandonado.
• Para equipos de 5-15 personas sin SRE dedicado, su coste operativo es significativamente menor que Kubernetes.
• La migración desde Docker Compose es la más suave posible: los mismos archivos YAML con el campo deploy: añadido.
• Kubernetes gana claramente en operators avanzados, autoscaling sofisticado y ecosistema CNCF.
• En self-hosted con 1-5 VPS, Swarm más Traefik cubre el 95% de las necesidades con el 20% del coste.

El estado real

Algunos hechos sobre el estado actual de Docker Swarm:

• Está integrado en Docker Engine — no es un proyecto aparte que pueda abandonarse independientemente.
• Recibe mantenimiento regular aunque sin features llamativas nuevas.
• Mirantis adquirió Docker Enterprise en 2019 y mantiene la tecnología — no es huérfano.
• Tiene adopción establecida en pequeñas y medianas organizaciones que no necesitan la complejidad de Kubernetes.

Lo que Swarm no es: no es lo más cool ni lo que verás en charlas de KubeCon, no tiene el ecosistema de operators de Kubernetes y no es opción para grandes hyperscale.

Cuándo Swarm es la mejor opción

Equipos pequeños sin SRE dedicado

Si tu equipo de desarrollo tiene 5-15 personas y no hay SRE/ops dedicados, Swarm cuesta significativamente menos operar:

• Setup en minutos frente a días.
• Conceptos limitados: services, stacks, secrets, configs, networks. Sin CRDs, operators ni Helm.
• docker stack deploy -c stack.yml mi-app y listo.
• Curva de aprendizaje compatible con saber Docker Compose.

Para una organización de 30-50 personas con 3-10 servicios, Swarm puede entregar el 95% del valor con el 20% del coste operativo.

Self-hosted en VPS

Para servicios en VPS propios de 1-5 nodos, Swarm es la herramienta natural. Kubernetes en este tamaño es over-engineering — la mayor parte de su valor aparece a escala que no tienes. Despliegues típicos:

• Sitios web propios y de clientes en pocos VPS.
• Stacks self-hosted: Nextcloud, Mailcow, Gitea, Plausible.
• Pequeñas empresas con infraestructura propia.

Migración suave desde Docker Compose

Si ya usas Compose en producción (síntoma común en pequeñas empresas), Swarm es el siguiente paso más natural. Los archivos docker-compose.yml funcionan casi sin cambios — solo añades el campo deploy: con replicas, resources y placement. Migrar a Kubernetes desde Compose requiere reescribir manifests y aprender conceptos nuevos. Swarm es continuidad.

Edge computing en mini-clusters

Para clusters de 3-10 nodos en edge (oficinas remotas, fábricas), Swarm es ligero, simple y suficiente. Kubernetes en edge requiere distribuciones especializadas como k3s o microk8s que añaden complejidad propia.

Cuándo Kubernetes es claramente mejor

Swarm no escala a todos los casos. Kubernetes gana cuando:

• Necesitas operators avanzados: PostgreSQL HA, Cassandra, Kafka clusters — Kubernetes tiene operators maduros.
• Multi-tenancy fuerte con namespaces: Swarm no tiene equivalente real.
• Autoscaling sofisticado: HPA/VPA, autoscalers basados en métricas custom.
• Service mesh, ingress controllers y GitOps maduro: todo el ecosistema CNCF asume Kubernetes.
• Hire-ability: mucha más gente conoce Kubernetes.
• Multi-cluster cross-region: Kubernetes con federación; Swarm es single-cluster.

Stack típico Swarm en producción

Cluster Swarm (1 manager + 2 workers, o 3 managers en HA)
   │
   ├── Traefik como proxy/ingress (con Let's Encrypt automático)
   ├── PostgreSQL/MariaDB como service de Swarm con volume bind
   ├── Apps en stacks separados (cada cliente o dominio = stack)
   ├── Portainer como UI de gestión
   ├── Prometheus + Grafana + Loki para observabilidad
   ├── Watchtower para auto-update (en monitor mode)
   └── Backups con restic a object storage externo

Este stack es operable por una persona, razonable de monitorizar y cubre la inmensa mayoría de necesidades de hosting compartido propio.

Comandos esenciales

Para alguien viniendo de Compose:

# Inicializar Swarm
docker swarm init --advertise-addr <ip>

# Añadir worker (token obtenido del manager)
docker swarm join --token <token> <manager-ip>:2377

# Desplegar stack desde docker-compose.yml
docker stack deploy -c stack.yml mi-app

# Listar servicios
docker service ls

# Ver logs de un servicio
docker service logs mi-app_web -f

# Escalar un servicio
docker service scale mi-app_web=3

# Actualizar imagen con rolling update
docker service update --image nginx:1.25 mi-app_web

Si sabes Compose, ya tienes el 70% de Swarm.

Limitaciones a asumir

Si eliges Swarm, asumes:

• Ecosistema limitado: Helm, ArgoCD, Backstage — todo eso es Kubernetes-only.
• Networking más simple (overlay VXLAN, no CNI con plugins).
• Sin RBAC granular comparable al de Kubernetes.
• Documentación y respuestas en foros escasas comparado con Kubernetes.

Para casos donde estas limitaciones no son problema, son trade-offs aceptables.

Relacionado: si necesitas GitOps sobre Swarm, las opciones son más limitadas que en Kubernetes — revisa si tiene sentido subir a k3s antes de implementar un pipeline complejo. Y para instalar Docker en Debian antes de configurar el cluster, lee cómo instalar Docker en Debian 12.

Conclusión

Docker Swarm está vivo y sigue siendo la elección correcta para casos donde Kubernetes es over-engineering. Equipos pequeños, self-hosted, mini-clusters edge — todos escenarios donde la simplicidad y bajo coste operativo de Swarm valen más que las features avanzadas de Kubernetes. El estigma “Swarm está muerto” es exagerado. La pregunta honesta es: ¿necesitas Kubernetes realmente, o necesitas algo simple que orqueste contenedores?