Portainer CE se queda en 2.x: qué hacer en tu VPS

Portainer CE se queda en 2.x, y tu VPS no se rompe

Portainer CE no desaparece. Se queda en la línea 2.x, con 2.45 LTS como última versión de esa serie, y sigue recibiendo parches de seguridad, corrección de errores y back-ports de funciones de 3.x allí donde exista una API de Docker equivalente. Lo que termina es la Community Edition como producto que avanza: no hay una compilación CE de la línea 3.x. Si seguiste nuestra guía para instalar Portainer en un VPS y hoy tienes ese contenedor en marcha, no hay nada urgente que hacer esta semana.

Nosotros alojamos el VPS. No vendemos el panel. Así que la respuesta honesta empieza por comprobar qué tienes instalado y termina, en la mayoría de los casos con un solo servidor, en «lo que tienes está bien».

Qué anunció Portainer exactamente, y qué fechas hay publicadas

El 11 de septiembre de 2026, Portainer publicó el artículo «Portainer 3.0 is coming, and here's what it means for you». Conviene citarlo en lugar de resumirlo, porque el resumen es justo donde se pierde el matiz. Sobre la edición comunitaria dice: «CE has been the community edition for the last ten years. It will continue on the 2.x codebase». Sobre el mantenimiento: «CE will continue to receive patches and updates because it is a core component of Business Edition 2.45 LTS». Es decir, CE continúa sobre el código 2.x y se sigue parcheando porque el mismo código es la base de la edición de pago 2.45 LTS.

El camino gratuito hacia 3.x existe, pero pasa por otro sitio: el programa «3 Nodes Free» de Business Edition. El anuncio afirma que «there are over 110,000 free Portainer Business licenses active today under '3 Nodes Free'» y que «3.x will be free to the community on exactly the same terms». Gratis en precio, no en licencia. Business Edition es software propietario que se activa con una clave emitida por el fabricante, incluso en su nivel gratuito, mientras que el código de Portainer CE se publica bajo la licencia zlib.

Sobre fechas, cuidado con lo que leas. El anuncio no publica ninguna fecha de fin de vida para CE. La política de ciclo de vida de Portainer, consultada el 22 de septiembre de 2026, sí lista 2.45 LTS con final de mantenimiento en mayo de 2027. Esa es la única fecha publicada, y es la que deberías apuntar en tu calendario. Nada más. Un titular que diga «Portainer gratis se acaba» confunde «deja de avanzar» con «deja de existir», y esas dos cosas piden decisiones muy distintas.

Como esta es una historia de un fabricante y puede moverse, vuelve a leer la fuente antes de decidir: el anuncio original y la página de ciclo de vida están en portainer.io, y ahí es donde cambian los números primero.

Cómo saber qué edición y versión de Portainer estás ejecutando

Antes de elegir ruta, comprueba qué hay corriendo. La edición se lee en el nombre de la imagen: portainer/portainer-ce es la Community Edition y portainer/portainer-ee es la Business Edition.

docker ps --filter name=portainer --format '{{.Names}}\t{{.Image}}'
docker inspect --format '{{.Config.Image}}' portainer

Una salida sana se parece a portainer portainer/portainer-ce:2.45.1. Si los comandos no devuelven nada, tu contenedor no se llama portainer: lista todo con docker ps y busca la imagen a ojo. Si el tag que ves es :latest, el nombre no te dice la versión, porque latest apunta a lo que se descargó el día que hiciste pull. En ese caso abre la interfaz web y mira el pie de la barra lateral, que imprime la versión y la edición en cada carga.

Ese dato importa más de lo que parece. Si ya estás en 2.45.x, estás en la línea LTS mantenida y no tienes que tocar nada. Si estás en 2.19 de hace tres años, tu problema no es el anuncio de 3.0, es que llevas tres años sin parches de seguridad en un panel que habla con el socket de Docker.

Ruta 1: quedarte en CE 2.45 LTS

Es la opción por defecto y, para un VPS, casi siempre la correcta. Actualizas a la última 2.45.x, sigues recibiendo parches y no cambias nada de tu operativa.

docker pull portainer/portainer-ce:2.45.1
docker stop portainer && docker rm portainer
docker run -d -p 9443:9443 --name portainer --restart=always \
  -v /var/run/docker.sock:/var/run/docker.sock \
  -v portainer_data:/data \
  portainer/portainer-ce:2.45.1

El volumen portainer_data es lo que hace que esto sea seguro: al recrear el contenedor conservas usuarios, ajustes y stacks. Fija el tag exacto en lugar de latest, porque así sabes qué versión estás ejecutando cuando algo falle. Después de arrancar, docker logs portainer no debe mostrar errores repetidos y la interfaz debe pedirte tu contraseña de siempre, no crear un usuario nuevo. Si te pide crear un administrador desde cero, el volumen no se montó y estás mirando una instalación vacía: para el contenedor antes de escribir nada.

El coste real de quedarte es que las funciones nuevas de 3.x llegarán solo cuando exista una API de Docker equivalente. Si tu uso es un VPS con contenedores Docker, esa limitación afecta poco, porque casi nada de lo que se construye sobre primitivas de Kubernetes tiene sentido en tu servidor.

Ruta 2: aceptar «3 Nodes Free» y una licencia cerrada

Si quieres 3.x sin pagar, esta es la vía. La página de precios define un nodo así: «Any server, VM, Raspberry Pi, desktop, laptop, industrial computer, or embedded device capable of running containers that is either running the Portainer Server or is managed by one». Traducido: cualquier máquina capaz de ejecutar contenedores que ejecute el servidor de Portainer o esté gestionada por él. Un VPS es un nodo, así que tres nodos cubren de sobra a quien tiene un servidor, y también a quien tiene un VPS más dos máquinas en casa.

Lo que entregas a cambio es el modelo de licencia. Pasas de código abierto bajo zlib a un producto propietario que requiere una clave, con unas condiciones que decide el fabricante y que puede revisar. Esa es una decisión editorial tuya, no técnica. Si lo que te importa es poder auditar y reconstruir lo que ejecutas, el límite de tres nodos no es el problema: el problema es el código cerrado.

Ruta 3: cambiar a Komodo o a Arcane

Hay dos proyectos abiertos que la gente está mirando después del anuncio. No son clones de Portainer y ninguno cubre su parte de Kubernetes, así que compáralos por lo que tú usas de verdad.

Komodo está escrito en Rust y gestiona stacks de compose, builds y despliegues desde Git sobre varios servidores. Su instalación oficial usa dos archivos descargados del repositorio:

wget -P komodo https://raw.githubusercontent.com/moghtech/komodo/main/compose/mongo.compose.yaml
wget -P komodo https://raw.githubusercontent.com/moghtech/komodo/main/compose/compose.env
docker compose -p komodo -f komodo/mongo.compose.yaml --env-file komodo/compose.env up -d

El archivo trae ghcr.io/moghtech/komodo-core:${COMPOSE_KOMODO_IMAGE_TAG:-2}, así que fija la versión en komodo/compose.env antes de arrancar, con una línea COMPOSE_KOMODO_IMAGE_TAG=2.3.3. Esa era la última estable publicada en la página de releases del proyecto el 22 de septiembre de 2026; comprueba cuál es la actual y usa esa. Abre komo.do en su documentación de instalación si quieres la variante con FerretDB en lugar de MongoDB. La interfaz queda en el puerto 9120.

Arcane es un binario en Go con interfaz web, licencia BSD-3-Clause, pensado para un servidor y no para una flota. Su documentación publica un compose con la imagen ghcr.io/getarcaneapp/manager, el puerto 3552, el socket de Docker montado y un ENCRYPTION_KEY de 32 bytes que debes generar tú. La documentación usa el tag latest: sustitúyelo por el número de versión que veas en su página de releases, para que una actualización no te llegue sola una madrugada. El usuario inicial es admin con contraseña password, y cambiarla es el primer paso después del primer arranque, no el segundo.

Estos comandos son para que los ejecutes tú en tu servidor. No los hemos verificado en nuestros contenedores de prueba, porque un solo contenedor Ubuntu no puede demostrar honestamente el comportamiento de cuatro interfaces web distintas. Lee la documentación oficial antes de pegar nada.

Los dos montan /var/run/docker.sock. Eso concede a la interfaz un control equivalente a root sobre el host, igual que Portainer. Cambiar de panel no cambia ese hecho, así que si te preocupa, el tema que tienes que leer es otro: qué interfaces de Docker funcionan en modo rootless.

Ruta 4: quitar el panel y conducir el VPS con docker compose

En un solo servidor al que ya entras por SSH, esta ruta quita una superficie de ataque y no te quita capacidad. Un stack se levanta, se inspecciona y se actualiza con cuatro comandos.

cd /srv/stacks/nextcloud
docker compose up -d
docker compose ps
docker compose logs -f --tail=50

docker compose ps debe mostrar cada servicio en estado running, y healthy si el servicio define un healthcheck. Un servicio en restarting que no se estabiliza en un minuto significa que el proceso muere al arrancar, y docker compose logs te dirá por qué. Si vienes de hacerlo todo con botones, empieza por los fundamentos de docker compose en un VPS y ten a mano una chuleta de comandos de docker compose durante las primeras semanas.

Qué te da realmente un panel sobre un servidor al que ya entras por SSH

Vale la pena decirlo en voz alta antes de elegir, porque mucha gente defiende el panel sin saber qué parte usa. Un panel web te da cuatro cosas concretas:

• Logs y consola de un contenedor desde el navegador, incluido el del móvil, sin abrir una sesión SSH.
• Una vista de volúmenes e imágenes con el espacio que ocupan, que responde más rápido que ir probando con docker system df.
• Acceso delegado: alguien puede reiniciar un servicio sin que le des una cuenta con sudo en el host.
• Un botón por stack que hace el pull y el up -d seguidos.

Lo que no te da es historial. La interfaz aplica el cambio y el estado anterior desaparece, así que seis meses después nadie sabe por qué ese contenedor tiene esa variable de entorno. Por eso la siguiente sección es la parte importante de este artículo, y no depende de qué panel elijas.

Tus stacks deben vivir en archivos compose versionados

Si creaste tus stacks escribiendo YAML en el editor web de Portainer, ese texto vive dentro de la base de datos del propio Portainer, en el volumen portainer_data, bajo /data/compose/. Mira qué hay ahí dentro:

docker run --rm -v portainer_data:/data alpine ls -1 /data/compose

Cada carpeta numerada es un stack, con su archivo compose dentro. Si esa es la única copia que existe, tu infraestructura depende de que ese volumen sobreviva, y de que el panel que lo lee siga funcionando. Eso es lo que convierte un cambio de licencia de un fabricante en un problema tuyo.

La solución es aburrida y funciona con cualquiera de las cuatro rutas: copia esos archivos a un directorio del host, por ejemplo /srv/stacks/<nombre>/compose.yaml, y ponlos en un repositorio Git. A partir de ahí el panel pasa a ser una ventana sobre tu servidor y deja de ser el sitio donde vive la verdad. Haz también una copia del volumen completo antes de tocar nada:

docker run --rm -v portainer_data:/data -v "$PWD":/backup alpine \
  tar czf /backup/portainer_data.tgz -C /data .

El archivo resultante debe pesar más de unos pocos kilobytes; si pesa casi nada, el volumen que nombraste no es el que usa tu contenedor, y lo confirmas con docker inspect portainer. Cuando ya tengas los compose en el host, el procedimiento de actualización deja de dar miedo, y eso es exactamente lo que cubrimos en cómo respaldar y actualizar un stack de docker compose.

Qué haría yo con un solo VPS

Quedarte. Actualiza a la última 2.45.x, fija el tag, saca tus stacks a archivos compose versionados en el host y sigue con tu vida. Tienes soporte publicado hasta mayo de 2027 según la página de ciclo de vida, lo que te da meses para mirar Komodo o Arcane con calma, cuando tengan más kilómetros encima y tú no estés decidiendo con prisa.

Migrar de panel el mismo fin de semana que sale una noticia es cómo se rompen servidores que funcionaban. La noticia es real, el cambio de licencia es real, y aun así tu contenedor de Portainer hará hoy exactamente lo mismo que hizo ayer.

FAQ

¿Portainer CE deja de ser gratis?

No. Portainer CE sigue siendo gratuita y de código abierto bajo licencia zlib, y se queda en la línea 2.x con 2.45 LTS como última versión de esa serie. Lo que cambia es que la nueva generación, 3.x, no tiene compilación CE: el acceso gratuito a 3.x pasa por el programa «3 Nodes Free» de Business Edition, que es software propietario activado con una clave de licencia.

¿Tengo que migrar mi VPS ahora mismo?

No. La página de ciclo de vida de Portainer, consultada el 22 de septiembre de 2026, lista 2.45 LTS con final de mantenimiento en mayo de 2027, y durante ese periodo la línea sigue recibiendo parches de seguridad y correcciones. Lo único que conviene hacer esta semana es comprobar tu versión con docker inspect --format '{{.Config.Image}}' portainer y actualizar si estás en una rama vieja.

¿Qué pierdo si me quedo en CE 2.45 LTS?

Pierdes las funciones nuevas que dependan de primitivas de Kubernetes, porque el anuncio dice que los back-ports llegan solo donde existe una API de Docker equivalente. En un VPS con contenedores Docker eso afecta poco. No pierdes parches de seguridad mientras la línea esté mantenida, porque ese mismo código es la base de la edición de pago 2.45 LTS.

¿Cuántos servidores cubre «3 Nodes Free»?

Tres nodos, y Portainer define un nodo como cualquier máquina capaz de ejecutar contenedores que ejecute el servidor de Portainer o esté gestionada por él, incluidos servidores, máquinas virtuales, una Raspberry Pi o un portátil. Un VPS cuenta como un nodo. El precio es cero y el coste es la licencia: código cerrado y una clave emitida por el fabricante.

¿Komodo y Arcane hacen lo mismo que Portainer?

No exactamente. Komodo gestiona stacks de compose, builds y despliegues desde Git sobre varios servidores, y Arcane es una interfaz de un solo servidor con licencia BSD-3-Clause. Ninguno cubre la parte de Kubernetes de Portainer. Los dos montan /var/run/docker.sock, así que el nivel de acceso que concedes a la interfaz web es el mismo que ya le dabas a Portainer.