Portainer 3.0: qué cambia si administras Docker (y a qué alternativa pasarte)

Portainer 3.0 no rompe tu servidor Docker a fin de mes. Lo que se acaba es otra cosa: no habrá Community Edition de la rama 3.x. Lo escribió el propio CEO, Neil Cresswell, en el anuncio oficial del 11 de septiembre de 2026: CE “seguirá en la base de código 2.x” y “no recibirá los cambios de 3.x”. La 3.x será gratis para la comunidad solo mediante el programa 3 Nodes Free, que es una licencia de Business Edition. Y 3.x es, en sus palabras, una base de código “Kubernetes-first”.

Si administras Docker —no Kubernetes— con Portainer CE, la decisión no corre prisa, pero hay que tomarla: quedarte en 2.x mientras dure, pedir la licencia gratuita de tres nodos y aceptar un producto pensado para Kubernetes, o salirte. Aquí van los hechos verificados en fuente primaria, qué se rompe en cada camino y qué elegir según tu caso. Yo corro Coolify en producción en dos VPS, así que al final también cuento lo que me ha mordido.

Lo que dice el anuncio, sin adornos

Lo de Reddit: “desaparece CE y solo queda Business gratis hasta 3 nodos”

Esa lectura circuló en r/selfhosted. Es correcta para la rama 3.x y se queda corta en todo lo demás. Esto es lo que confirma la fuente primaria:

• Cierto: no habrá edición CE de 3.x, y la forma gratuita de usar 3.x es 3 Nodes Free. La página del programa dice que es una licencia de Business Edition, que la mandan tras llenar un formulario y que está “limitada a una licencia por organización”.
• Incompleto: CE no desaparece mañana. Sigue en la rama 2.x, el repositorio portainer/portainer mantiene su licencia zlib y la política de ciclo de vida da a la 2.45 LTS mantenimiento hasta mayo de 2027.
• El matiz que casi nadie menciona: la licencia de tres nodos caduca y hay que renovarla. La documentación dice que la llave nueva no llega hasta 14 días antes de que venza la actual. CE no pedía formulario ni renovación.
• Qué cuenta como nodo: según la FAQ de licencias, en Docker cuenta cualquier servidor que ejecute Portainer Server o el Agent. Tres hosts Docker (uno con el server y dos con agente) son tres nodos: ya agotaste la cuota gratuita.

Un aviso sobre esa fecha de mayo de 2027: la misma página de ciclo de vida todavía anuncia una 2.46 STS para septiembre y una 2.51 LTS para febrero de 2027, algo que el anuncio contradice, porque la 2.45 es la última 2.x. La tabla no se ha actualizado desde el anuncio, así que toma mayo de 2027 como la fecha publicada, no como una garantía. El anuncio no le pone fecha de fin a la rama 2.x.

Qué se rompe (y qué no) en cada camino

Camino 1: te quedas en Portainer CE 2.45

Hoy no se rompe nada. Pero hay dos cosas que conviene hacer esta semana.

Fija la versión exacta de la imagen. En Docker Hub, las etiquetas lts, sts y latest de portainer/portainer-ce se actualizaron por última vez el 27 de agosto, con la 2.45.0. No encontré documentado a qué van a apuntar cuando salga la 3.0 STS, así que si usas Watchtower o algo parecido, no dejes que una etiqueta flotante decida por ti:

services:
  portainer:
    image: portainer/portainer-ce:2.45.0   # no :latest ni :sts

Asegúrate de estar en 2.45.0 (o en 2.39.7 si sigues en la LTS anterior). Las notas de la 2.45.0 corrigen un bypass crítico de autorización en el proxy de Docker: los prefijos de versión de API no reconocidos, como /v1.47.0/, se saltaban el control de acceso y dejaban a usuarios sin permisos de administrador hablar directo con la API de Docker. La 2.39.7 LTS recibió el mismo arreglo el mismo día.

Para ver qué imagen estás corriendo:

docker ps --filter name=portainer --format '{{.Image}}'

Si te quedas, pierdes las funciones nuevas y ganas tiempo para decidir.

Camino 2: pasas a 3.x con la licencia de 3 nodos

Tus entornos Docker nativos siguen funcionando; en eso el anuncio es explícito. Lo que cambia son las condiciones: una licencia Business que caduca, un tope de tres nodos, un producto cuya hoja de ruta ya no incluye a Docker y una 3.0 que sale como STS (la LTS llega en diciembre con la 3.3.0). Si administras más de tres hosts, este camino es de pago.

Tiene un lado bueno si tu Portainer lo usan varias personas: el control de acceso por roles (RBAC) es de Business Edition, según la documentación de roles, así que con 3 Nodes Free lo tendrías.

Camino 3: sigues la recomendación de Portainer y migras a D2K

Aquí sí se rompen cosas, y no por un bug, sino por diseño. D2K (licencia MIT) expone la API de Docker y traduce cada llamada a objetos de Kubernetes dentro de un namespace. Su propio README enumera lo que no soporta y aclara que “no se añadirá”:

Si tu compose construye la imagen en el mismo servidor, si aíslas la base de datos en una red interna o si tienes algo con network_mode: host, D2K no es una migración: es un rediseño. Y debajo sigue habiendo un Kubernetes que operar.

Las alternativas, verificadas

Revisé el repositorio, la licencia y el último release de cada una el 13 de septiembre de 2026.

Coolify: si lo que haces con Portainer es desplegar tus propias apps

• Licencia: Apache-2.0. Unas 61 700 estrellas en GitHub.
• Madurez: la v4.0.0 estable salió el 27 de abril de 2026 y el último release es la v4.3.19, del 10 de septiembre. Entre el 3 y el 10 de septiembre publicó cuatro versiones.
• Qué es: un PaaS self-hosted, no una UI de contenedores. Despliega desde git (Nixpacks, Railpack, Dockerfile, Docker Compose o sitio estático), pone el proxy inverso (Traefik o Caddy) con certificados, programa respaldos de bases de datos, trae más de 280 servicios de un clic y administra varios servidores por SSH.
• Usuarios: equipos, 2FA y OAuth con Azure, Bitbucket, Clerk, Discord, GitHub, GitLab, Google, Authentik, Infomaniak y Zitadel (la lista sale del código fuente).
• Requisitos: 2 núcleos, 2 GB de RAM y 10 GB de disco, según su documentación, que además recomienda un servidor limpio para evitar conflictos con lo que ya corre.
• Qué no es: un panel para contenedores que levantaste a mano. Su modelo es que el despliegue lo haga él.
• Swarm: deprecado. El aviso del propio código dice que se elimina en Coolify v5 y que no recomiendan montar despliegues Swarm nuevos.

Komodo: el reemplazo más directo de Portainer para varios servidores

• Licencia: GPL-3.0. Unas 12 200 estrellas. Último release: v2.3.3, del 1 de septiembre de 2026; la v2.0.0 salió el 24 de marzo.
• Qué hace: conecta servidores (con un agente llamado Periphery en cada uno), despliega contenedores y stacks de Compose definidos en la UI, en el host o en un repo de git, con redespliegue automático por webhook. También construye imágenes, corre automatizaciones programadas y registra quién hizo cada cambio y cuándo.
• Swarm: soportado desde la v2.0.0 (clústeres, nodos, servicios, stacks, configs y secrets).
• Usuarios: usuario y contraseña con 2FA, OAuth con GitHub, Google y OIDC genérico, y permisos granulares por roles.
• Límite de servidores: ninguno, “y nunca lo habrá”, según su README.
• Requisitos: Docker, más MongoDB o FerretDB (sobre Postgres) para el Core. De esta lista, es la que más infraestructura te pide, y su documentación da por hecho que el proxy inverso lo pones tú.

Dockge: si solo quieres editar tus compose.yaml desde el navegador

• Licencia: MIT. Unas 24 300 estrellas. Es del mismo autor que Uptime Kuma.
• Madurez: último release 1.5.0, del 30 de marzo de 2025; el último commit en master es de abril de 2026. El mantenimiento va lento.
• Qué hace: crea, edita, arranca y actualiza stacks de Compose, con terminal web, y convierte comandos docker run a compose. Tus archivos se quedan en disco (/opt/stacks por defecto) y los puedes seguir usando con docker compose. Desde la 1.4.0 maneja varios hosts mediante agentes.
• Qué no hace: tiene una sola cuenta. El setup se niega a crear un segundo usuario, y el PR que añadía usuarios y grupos (#891) se cerró sin fusionar en julio de 2026. No hay SSO ni roles, y el README no menciona despliegue desde git.

Dockhand: la UI más completa, con letra pequeña en la licencia

• Existe y avanza rápido: el repositorio Finsys/dockhand se creó en diciembre de 2025, tiene unas 6200 estrellas y su último release es la v1.0.47, del 12 de septiembre de 2026.
• Qué hace: contenedores, stacks de Compose con editor visual, despliegue desde git con webhooks, varios hosts (por socket, por TCP con TLS o con Hawser, su agente MIT, que se conecta hacia afuera sin abrir puertos), escaneo de vulnerabilidades con Grype y Trivy, respaldos (en beta) y OIDC/SSO gratis. Usa SQLite por defecto o PostgreSQL, y dicen que corre en una Raspberry Pi 4.
• Qué no hace: Swarm; hay un issue abierto pidiéndolo. RBAC, LDAP/Active Directory y la auditoría para cumplimiento son de la edición Enterprise (1499 dólares por host al año).
• La licencia se contradice. El LICENSE.txt del repositorio es la Business Source License 1.1 con una concesión adicional que permite explícitamente el “uso interno de negocio” en producción, siempre que no lo ofrezcas como SaaS de gestión de Docker; pasa a Apache-2.0 el 1 de enero de 2029. Pero los términos de licencia de su sitio dicen que un usuario comercial necesita licencia de pago para entornos de producción o instancias compartidas, y su tabla de precios coloca la “licencia de uso comercial” en el plan SMB (499 dólares por host al año). En un homelab no hay duda. Si eres empresa, pídeles la aclaración por escrito antes de meterlo a producción.

Lazydocker y Yacht, para completar

• Lazydocker (MIT, unas 52 800 estrellas, v0.25.2 de abril de 2026) es una interfaz de terminal, no un servidor web: no hay usuarios, ni agentes, ni nada que exponer. Si usabas Portainer solo para ver logs y reiniciar contenedores, te basta.
• Yacht volvió a publicar en septiembre de 2026 (release 1.1) después de años sin releases; el anterior, v0.0.7-alpha, es de 2021. Es muy pronto para confiarle producción.

La tabla de decisión

Lo que he aprendido corriendo Coolify en dos VPS

Tengo Coolify en producción en dos servidores: uno con este sitio y aplicaciones de clientes, y otro con herramientas internas. Hay tres cosas que ninguna comparativa te cuenta, y aplican a cualquier herramienta que hable con el socket de Docker, Portainer, Dockge y Dockhand incluidos.

1. Después de actualizar docker-ce, reinicia los contenedores que montan el socket. En mayo de 2026 actualicé Docker de la 29.5.0 a la 29.5.2 con live-restore activado. Las apps siguieron vivas, pero el proxy de Coolify (Traefik con el proveedor de Docker) se quedó en un bucle intentando reconectarse a /var/run/docker.sock. Resultado: 502 en todas las apps que enruta a través de Docker, mientras el dashboard, que va por archivo de configuración, seguía respondiendo, y eso despista. live-restore protege a los contenedores, no las conexiones que tenían abiertas contra el socket. Desde entonces, después de cada actualización corro:

docker restart coolify-proxy coolify-sentinel

O, en general, reinicio todo contenedor que monte el socket:

for c in $(docker ps --format '{{.Names}}'); do
  docker inspect -f '{{range .Mounts}}{{if eq .Source "/var/run/docker.sock"}}{{$.Name}}{{end}}{{end}}' "$c" | grep -v '^$'
done | xargs -r -n1 docker restart

Ojo: desde la v4.3.19 Sentinel es obligatorio en los servidores normales de Coolify, así que el reinicio de coolify-sentinel ya aplica a todas las instalaciones.

2. Docker se salta UFW. Cuando instalé Coolify en el segundo VPS, los puertos del dashboard y del servicio de tiempo real quedaron abiertos a internet aunque UFW no los permitía: los puertos que publica un contenedor pasan por reglas de iptables que Docker gestiona antes de que UFW los vea. Lo resolví con reglas DROP en la cadena DOCKER-USER, filtrando por el puerto de destino original de la conexión (conntrack --ctorigdstport, porque cuando el paquete llega a esa cadena el DNAT ya reescribió el puerto), y dejando públicos solo el 80 y el 443. Si instalas cualquiera de estas UIs publicando un puerto, compruébalo desde fuera del servidor; no te fíes de ufw status.

3. Las reglas de firewall atadas a la IP de un contenedor se rompen al reiniciar. En el servidor de producción, tras un reinicio, todos los dominios daban timeout aunque Traefik estaba sano. Las reglas de ufw-docker apuntaban a la IP interna vieja del proxy, y el proxy arrancó con otra. El arreglo que aguanta fue permitir el 80 y el 443 hacia el rango de redes de Docker, no hacia una IP concreta. Reiniciar Docker no lo arregla, porque las reglas son de UFW.

Y una que viene en la propia documentación de Coolify y que confirmo: crea la cuenta de administrador en cuanto termine la instalación. Quien llegue primero a la página de registro se queda con el control del servidor.

Si vas a copiar tus stacks de Portainer a otra herramienta, valida cada compose.yaml contra el esquema oficial antes del primer despliegue:

Veredicto

Si usas Portainer CE con Docker, no migres este mes. La 2.45 LTS sigue mantenida, la 3.0 sale como STS y la primera LTS de 3.x no llega hasta diciembre. Fija la imagen en 2.45.0 y usa los próximos meses para probar la alternativa que te toque en un servidor que no sea el de producción.

Pero no esperes una CE 3.x, porque no va a existir. El Portainer que conocías —gratis, sin registro, sin tope de nodos y con Docker como prioridad— se queda congelado en 2.x.

Para elegir, pregúntate qué haces de verdad con Portainer. Si despliegas tus propias apps, el salto natural es Coolify, y es lo que yo uso. Si administras stacks en varios servidores con un equipo, Komodo es lo más parecido a lo que era Portainer, sin tope de nodos y sin licencia comercial. Si eres tú solo con tu homelab, Dockge si te basta lo mínimo, o Dockhand si lo quieres todo. Y si ya ibas camino a Kubernetes, Portainer 3.x está hecho para ti; D2K solo tiene sentido si tus stacks no construyen imágenes ni dependen de redes especiales.

Para seguir leyendo:

• Guía completa de Docker en 2026: Compose v5, Engine 29 y la comparación entre Compose, Swarm y Kubernetes para producción.
• Kubernetes 1.37: qué se rompe al actualizar: si al final te vas a Kubernetes, con D2K o sin él, esto es lo que hoy bloquea una actualización.

Preguntas frecuentes

¿Portainer Community Edition desaparece con la versión 3.0?

No de inmediato, pero no tendrá versión 3.x. Según el anuncio oficial del 11 de septiembre de 2026, CE sigue en la base de código 2.x y no recibirá los cambios de 3.x. Portainer no va a publicar una build CE de 3.x: la forma gratuita de usar 3.x es el programa 3 Nodes Free, que es una licencia de Business Edition. La política de ciclo de vida de Portainer da a la 2.45 LTS mantenimiento hasta mayo de 2027.

¿Qué es Portainer 3 Nodes Free y qué limita?

Es una licencia de Portainer Business Edition gratuita para hasta tres nodos, limitada a una licencia por organización y que se pide con un formulario. La licencia caduca y hay que renovarla: la llave nueva se envía hasta 14 días antes del vencimiento. En Docker cuenta como nodo cualquier servidor que ejecute Portainer Server o el Portainer Agent, así que tres hosts Docker ya agotan la cuota.

¿Mis entornos Docker dejan de funcionar si actualizo a Portainer 3.x?

No. El anuncio dice que los entornos Docker, Swarm y Podman nativos se pueden seguir agregando y siguen funcionando desde la interfaz. Lo que cambia es que quedan en segundo plano y no recibirán capacidades nuevas del motor de políticas, de GitOps ni de observabilidad. Los productos nuevos, Portainer-Run, IDP, Command y AiGrid, son solo para Kubernetes.

¿Hasta cuándo recibe parches Portainer 2.45 LTS?

La política de ciclo de vida publicada en la documentación de Portainer marca mayo de 2027 como fin de soporte y mantenimiento de la 2.45 LTS. El anuncio de 3.0 dice que la rama 2.x seguirá recibiendo actualizaciones de seguridad, corrección de bugs y back-ports selectivos, sin dar fecha de fin. Esa tabla de ciclo de vida aún lista versiones 2.46 a 2.51 que el anuncio contradice, así que conviene tomar mayo de 2027 como la fecha publicada y no como garantía.

¿Qué es Portainer D2K y qué no soporta?

D2K es un traductor de Docker a Kubernetes con licencia MIT: expone la API de Docker y convierte cada llamada en objetos de Kubernetes dentro de un namespace. Según su README, ignora la directiva build de Compose, no soporta docker build, load, save ni buildx, no soporta redes macvlan ni ipvlan, no tiene equivalente para network host, IP o MAC fijas, no aplica aislamiento de red entre stacks y convierte los bind mounts en hostPath, que no son fiables en clústeres de varios nodos.

¿Cuál es la mejor alternativa gratuita a Portainer para Docker?

Depende de para qué lo usas. Para varios servidores y varias personas, Komodo (GPL-3.0) no tiene límite de servidores e incluye roles y OIDC, aunque necesita MongoDB o FerretDB. Para una sola persona que edita archivos compose, Dockge (MIT) es lo más simple, pero admite una sola cuenta. Para desplegar tus propias apps desde git con proxy y certificados, Coolify (Apache-2.0). Dockhand es la interfaz más completa, pero su licencia comercial es ambigua.

¿Coolify sirve como reemplazo de Portainer?

Solo si lo que haces con Portainer es desplegar tus propias aplicaciones. Coolify es un PaaS self-hosted: despliega desde git con Nixpacks, Railpack, Dockerfile o Docker Compose, configura Traefik o Caddy con certificados y programa respaldos de bases de datos. No está pensado para administrar contenedores creados a mano, su documentación recomienda un servidor limpio y su soporte de Docker Swarm está deprecado y se eliminará en Coolify v5.

¿Dockhand es gratis para uso comercial?

No está claro, porque sus dos textos de licencia se contradicen. El LICENSE.txt del repositorio es la Business Source License 1.1 con una concesión que permite el uso interno de negocio en producción, siempre que no se ofrezca como SaaS. Los términos de licencia de dockhand.pro, en cambio, exigen licencia de pago a usuarios comerciales en producción o en instancias compartidas, y la tabla de precios pone la licencia de uso comercial en el plan SMB de 499 dólares por host al año. Para uso personal es gratis sin ambigüedad.