Portainer 3.0 mira hacia Kubernetes. ¿Y los que lo usamos en el homelab?

Tabla de contenido

Fecha de corte: 23 de septiembre de 2026. Portainer 3.0 está anunciado, pero todavía no publicado. La última versión estable oficial es 2.45.1 LTS, publicada el 17 de septiembre. Portainer sitúa 3.0 STS como previsión para octubre.3 4

Usé Portainer durante mucho tiempo, aunque sus menús siempre me parecieron algo liosos. Me gustaba lo que podía hacer con él, pero no siempre cómo estaba organizado. Tener Docker, Podman y Kubernetes en un mismo lugar sigue pareciéndome uno de sus grandes aciertos. Cuando quieres administrar entornos distintos, hay mucho valor en no tener que cambiar de herramienta para cada uno.

Dockge me gustó mucho, aunque me parecía demasiado simple. Con Arcane fue bastante flechazo: tenía ese aspecto moderno, era fácil de usar y me daba la sensación de encontrar las opciones que buscaba sin pelearme con los menús. Hoy me gusta más para Docker. Eso no me impide apreciar lo que ofrece Portainer cuando sales de ese entorno.

Con ese recorrido, el anuncio de Portainer 3.0 me dejó pensando. Yo había encontrado una interfaz que me encajaba mejor. Portainer, mientras tanto, está preparando un producto cuyo desarrollo girará alrededor de Kubernetes. Para quienes lo conocimos administrando contenedores Docker, merece la pena detenerse en lo que eso supone. Sobre todo si todavía lo usas a diario y te preguntas cuánto va a cambiar tu instalación.

Leí la noticia en Virtualization Howto y fui al anuncio de Portainer y a su aclaración posterior.1 2 Docker seguirá siendo compatible. Lo que cambia es cuánto del futuro de Portainer estará pensado para él, y ahí sí hay motivos para mirar con calma las opciones.

Qué versión puedes instalar hoy
#

Conviene empezar aquí porque el nombre 3.0 invita a pensar en una descarga disponible. A fecha de corte, no lo está. El anuncio oficial de Portainer dice que 2.45 LTS será la última entrega de la familia 2.x y que 3.0.0 llegará primero como STS. Su política de ciclo de vida sitúa esa STS en octubre y una 3.3 LTS en diciembre, pero ambas fechas son orientativas.2 3

Mientras tanto, la rama que existe es 2.45.1 LTS. El repositorio oficial la marca como la última release y la fecha de publicación es el 17 de septiembre. La política actual mantiene 2.45 LTS hasta mayo de 2027.3 4

Si tienes un homelab estable con Docker, puedes mantenerlo en una rama que todavía recibe correcciones. No hay necesidad de preparar una migración urgente. Una STS sirve a quien quiere recibir funciones antes y acepta actualizar más a menudo. En una máquina donde viven servicios de casa, preferiría la rama LTS.

El sitio al que Portainer quiere ir
#

Portainer explica el cambio con bastante franqueza. Mantener el mismo nivel de producto sobre Docker, Podman, Swarm y Kubernetes deja de ser sostenible cuando entran políticas, GitOps, observabilidad y control de acceso. La base de 3.x será Kubernetes-first.2

Portainer afirma que seguirá permitiendo añadir y administrar entornos Docker, Swarm y Podman nativos. También dice que 2.45 LTS, tanto Community Edition como Business Edition, seguirá recibiendo correcciones y cambios retroportados cuando haya una API Docker equivalente. Las capacidades nuevas se diseñarán alrededor de Kubernetes.2

Lo que no promete es paridad. Una política de red de Kubernetes, un estándar de seguridad de pods o un controlador de admisión no tienen una traducción directa para un host Docker o un Swarm. Los productos nuevos que enumera Portainer, como Run, IDP, Command y AIGrid, se plantean para Kubernetes. Portainer-Run ya figura como disponible en el anuncio. Eso no equivale a decir que Portainer 3.0 esté publicado.2

Hay bastante lenguaje de plataforma en esa lista. GitOps, por ejemplo, consiste en guardar en Git el estado deseado y aplicar cambios mediante un flujo controlado. Command se presenta como una puerta MCP para que un agente pueda consultar y proponer cambios a través de GitOps. En una organización con equipos y clústeres, se entiende el interés. En el mini PC donde tienes Immich, Home Assistant y el proxy inverso, quizá estás resolviendo un problema que todavía no tienes.

Portainer no se ha vuelto peor por elegir ese rumbo. Está invirtiendo en un tipo de operación diferente. A quienes seguimos con Compose nos toca decidir si eso nos afecta hoy o solo nos da una ruta para aprender mañana.

Para seguir con Compose hay opciones
#

Aquí es donde me parece fácil confundirse. Arcane puede resultar más agradable para gestionar Docker. Dockge puede ser justo lo que necesitas si quieres tocar compose.yaml sin rodeos. Portainer puede seguir siendo la opción con más alcance si manejas más de un tipo de entorno. Ninguna de esas preferencias obliga a migrar de Docker a Kubernetes.

Docker Compose sigue siendo una elección muy razonable cuando entiendes tus servicios, tienes los YAML guardados fuera de la interfaz y puedes restaurar sus datos. A veces la opción más tranquila es docker compose por SSH y un repositorio privado con el estado declarado. No queda tan bien en una captura, pero una UI no debería ser el único lugar donde vive el conocimiento de tu infraestructura.

Si usas Dockge, su enfoque está claro: gestionar ficheros Compose normales, arrancar y actualizar pilas, incluso en varios hosts con agentes. El propio proyecto no pretende cubrir todo lo que Portainer ofrece sobre redes o contenedores individuales.10 Arcane se presenta como gestor moderno de Docker y publica su código bajo BSD de tres cláusulas. Antes de mover algo importante, miraría sus permisos sobre el socket, las funciones que realmente necesito y la actividad del proyecto. No lo trataría como una equivalencia demostrada de Portainer.11

Cambiar de Portainer a otra interfaz para Docker permite conservar el motor que ejecuta los contenedores. Pasar esos servicios a Kubernetes requiere revisar bastantes más cosas. Esa es la parte del anuncio en la que más me detendría antes de tocar un servidor que ya funciona.

D2K puede acercar Docker a Kubernetes, con condiciones
#

D2K es la pieza que hace más interesante el anuncio para quien viene de Docker. Es un traductor de la API de Docker Engine a operaciones Kubernetes. Expone la API en los puertos 2375 y 2376, puede recibir llamadas de la CLI, de SDKs o de Portainer y trabaja dentro de un único namespace por instancia. Puede emular un host Docker o Swarm.5

Eso permite que una orden familiar se convierta en objetos Kubernetes. Un docker run puede terminar como Deployment y Pod. Un volumen nombrado puede convertirse en un PersistentVolumeClaim. Un puerto publicado puede acabar como Service de tipo LoadBalancer.5

La parte importante llega justo después de esa lista. D2K no es Docker ejecutándose dentro de Kubernetes. Es una capa de traducción con límites documentados. No construye imágenes, no las etiqueta y no las sube a un registro. Si un Compose depende de build:, D2K lo ignora. Las imágenes tienen que existir ya en un registry.5

Tampoco conserva todo el comportamiento de Compose. depends_on no garantiza orden de arranque porque Kubernetes no tiene esa primitiva. Los healthchecks de Compose no se transforman en probes de disponibilidad o vivacidad. Un servicio global no se convierte en DaemonSet, sino que se degrada a una réplica con advertencia.5

Son detalles que parecen menores hasta que el servicio necesita que una base de datos esté lista, no solamente iniciada. Ahí no ayuda que la interfaz acepte la orden si el modelo de ejecución ya es otro.

Esa carpeta del NAS también tiene que llegar al destino
#

Los bind mounts son un ejemplo muy terrenal. D2K los representa como hostPath. En un clúster con varios nodos, esa ruta debe existir en el nodo donde Kubernetes programe el pod. Una carpeta de tu NAS no aparece por arte de magia en el resto de nodos.5

Las redes también cambian. D2K describe sus redes como sintéticas y el namespace queda con red plana, sin aislamiento real por cada red Compose. Macvlan e ipvlan no están soportadas en este modelo porque necesitan acceso de capa 2. No es una limitación universal de Kubernetes. Es una limitación de D2K que importa mucho si un contenedor necesita IP propia en la LAN, una ruta concreta o hablar con un dispositivo local.5

Ojo con otro caso menos evidente. Si en Docker publicas 127.0.0.1:8080:80, el README de D2K dice que ignora la IP del host y avisa de ello. No hay que asumir que un servicio limitado al propio equipo conserva esa restricción al traducirse. Tras una prueba, toca comprobar desde dónde queda expuesto y qué control está aplicando el clúster.5

En almacenamiento, los volúmenes nombrados sin opciones se traducen a una solicitud de 1 GiB con ReadWriteOnce sobre la StorageClass predeterminada.5 Eso no mueve las fotos ni la base de datos que ya tenías en Docker. Y ReadWriteOnce no significa una única réplica o un único pod por definición. Describe el modo de acceso del volumen. Tampoco añade alta disponibilidad por sí solo.

La disponibilidad la deciden el clúster, el almacenamiento, cómo expones el servicio y la propia aplicación. Cambiar la API que hay delante de un contenedor no convierte sus datos en replicados ni una aplicación en recuperable tras un fallo.

Antes de migrar, copia algo que puedas restaurar
#

Portainer ha anunciado un complemento para convertir contenedores y stacks Docker en manifiestos Kubernetes, hacer commit en Git y desplegar por GitOps. Es una función anunciada para el futuro, no una herramienta sobre la que organizar hoy una migración doméstica.2

Lo primero no es abrir un asistente. Es separar qué tienes. Por un lado está la configuración: Compose, variables, secretos, puertos, imágenes y etiquetas. Por otro, los datos de aplicación: bases de datos, fotos, bibliotecas, índices y certificados. Luego está el estado propio de Portainer, como portainer_data, usuarios y endpoints.

Copiar solo portainer_data no protege los datos de Nextcloud o Immich. Guardar solo los YAML tampoco restaura una base de datos. La copia útil es la que puedes restaurar y comprobar con la aplicación arrancada.

Yo empezaría con una aplicación prescindible en una VM o un nodo aparte, sin reutilizar los volúmenes de producción. Probaría los permisos y los puertos, comprobaría dónde se guardan los datos y reiniciaría el entorno para ver si todo vuelve como esperaba. Mantendría el despliegue Docker original hasta completar una restauración en el destino. Si esa prueba falla, prefiero descubrirlo con datos de prueba.

CE, Business gratis y el coste de crecer
#

Otro matiz que merece atención es la licencia. Con 3.x no habrá una nueva compilación Community Edition. CE continúa en 2.x. Para la comunidad, Portainer ofrece 3.x mediante Business Edition para tres nodos gratuitos, con una licencia por organización.2 8

Gratis no significa que sea el mismo producto ni el mismo acuerdo que CE. El README de Portainer define CE como opción gratuita y autogestionada para Docker, Swarm, Podman, Kubernetes y ACI, orientada a homelabs, aprendizaje y proyectos personales, sin soporte oficial ni compromiso de roadmap.9

Para un homelab no comercial que supere tres nodos, la referencia pública actual para Home & Student es 155 dólares al año hasta 15 nodos. Portainer indica que no es para uso comercial.7 Antes de diseñar una topología alrededor de la versión gratuita conviene contar nodos, no contenedores, y leer las condiciones vigentes cuando 3.x se publique.

Lo que haría ahora con un homelab Docker
#

No migraría por el anuncio. Pondría orden en los stacks y actualizaría dentro de la rama LTS siguiendo la ruta admitida. Guardaría Compose y documentación fuera de Portainer. Revisaría los datos que no quiero perder y haría una prueba de restauración de verdad.

Seguir usando Portainer tiene todo el sentido si es la vista que necesitas para Docker, Podman, Swarm o Kubernetes. Que hoy me atraiga más Arcane para Docker no borra esa capacidad. Dockge encaja si quieres una herramienta más centrada en Compose. Son decisiones de interfaz que pueden convivir con el mismo runtime.

Y si te apetece aprender Kubernetes, D2K y KubeSolo pueden ser un laboratorio interesante. El proyecto KubeSolo se publica bajo MIT como Kubernetes ultraligero y su repositorio mostraba v1.2.0 en agosto.6 Empezaría sin servicios críticos y con una lista concreta de incompatibilidades que comprobar. No con la idea de que “Docker compatible” significa idéntico.

Cuando salga 3.0, me interesará ver cómo queda la gestión de Docker nativo y cuánto peso tiene en la nueva interfaz. Hasta entonces, mi preferencia por Arcane sigue siendo una cuestión de uso, no una recomendación para que todo el mundo abandone Portainer. Si lo utilizas para administrar varios tipos de entorno y estás cómodo, seguir con él tiene bastante sentido. Solo dejaría apuntado ese mayo de 2027 para revisar el mantenimiento de 2.45 con margen, sin esperar a que venza.