Qué cambia Portainer 3.0 para los usuarios de la CE
Desde sus inicios, Portainer Community Edition permitía gestionar contenedores Docker y stacks Compose a través de una interfaz web, de forma gratuita, sin límite de nodos. Portainer 3.0 cambia este modelo: la CE desaparece en favor de una edición única con una capa gratuita restringida y un plan Business de pago.
En la práctica, las funcionalidades avanzadas — gestión de múltiples entornos, RBAC, integraciones de autenticación externa — pasan a estar detrás de una suscripción. Para un desarrollador independiente o una agencia que gestiona varios VPS, el coste puede volverse significativo.
La buena noticia: el ecosistema open source de gestión de contenedores ha crecido considerablemente desde 2022. Tres herramientas cubren ahora los principales casos de uso, cada una con un enfoque diferente.
Los tres perfiles de migración
- Servidor único, simplicidad ante todo → Dockge: interfaz ligera, stacks Compose, cero dependencias.
- Despliegue de apps completas, PaaS self-hosted → Coolify: reverse proxy integrado, SSL automático, despliegue desde Git.
- Multi-servidor, GitOps, equipos → Komodo: orquestación centralizada, Core < 256 MB RAM, disponible en el catálogo ServOrbit.
- Las tres herramientas están bajo licencias open source, sin nivel de pago para funcionalidades core, y están activamente mantenidas en 2026.
Dockge — gestión Compose sin la complejidad
Dockge es un gestor de stacks docker-compose.yml desarrollado por el creador de Uptime Kuma. No pretende reemplazar Portainer por completo: apunta a un ámbito preciso, gestionar y desplegar archivos Compose desde una interfaz web minimalista.
Puntos fuertes: en marcha en dos comandos, interfaz reactiva, edición en línea de archivos Compose, logs en tiempo real. Puntos débiles: un único host Docker, sin RBAC, sin gestión multi-servidor.
Dockge es ideal para desarrolladores que gestionan un VPS personal y simplemente quieren visualizar, iniciar o detener sus stacks sin abrir un terminal. Una comparativa detallada Dockge vs Portainer está disponible en el artículo portainer-vs-dockge-gestion-conteneurs-vps.
Coolify — PaaS self-hosted con SSL y reverse proxy integrados
Coolify se posiciona como un Heroku o Render que tú mismo alojas. Va más allá de la gestión de contenedores: gestiona el despliegue desde Git (push-to-deploy), configura automáticamente el reverse proxy (Traefik) y renueva los certificados SSL.
Puntos fuertes: despliegue desde GitHub/GitLab/Gitea en pocos clics, soporte para Dockerfile, Docker Compose y Nixpacks, interfaz moderna, soporte multi-servidor (nodos remotos añadidos vía SSH). Puntos débiles: más pesado en idle que un gestor Compose puro, curva de configuración inicial más pronunciada.
Coolify es ideal para agencias o desarrolladores que despliegan regularmente aplicaciones desde un repositorio Git y quieren evitar configurar nginx y Certbot manualmente para cada proyecto.
Komodo — orquestación multi-servidor y GitOps
Komodo (antes conocido como Monitor) es el más completo de los tres. Bajo licencia GPL-3.0, ofrece una arquitectura Core/Periphery: un Core central orquesta agentes Periphery desplegados en cada servidor. Gestiona despliegues Docker y Docker Compose, sincroniza stacks desde un repositorio Git, centraliza logs y alertas, y expone una API.
El Core de Komodo consume menos de 256 MB de RAM en idle — cabe en el mismo VPS de entrada de gama que tus apps. Es la alternativa más cercana a Portainer en términos de alcance funcional, y la única de las tres que cubre nativamente el caso multi-servidor con GitOps.
Para una guía de instalación completa, consulta la guía dedicada: self-host-komodo-vps. Komodo también está disponible directamente desde el catálogo ServOrbit.
Desplegar Komodo Core en un VPS ServOrbit
Requisitos previos
Un VPS con acceso root, Docker y Docker Compose instalados. Cuenta con 1 vCPU y 512 MB de RAM mínimo para el Core solo (menos de 256 MB en idle). Se recomienda un dominio o subdominio apuntando a tu VPS para el acceso HTTPS.
Crear el directorio y el archivo Compose
Conéctate vía SSH, luego:
mkdir -p /opt/komodo && cd /opt/komodoCrea un archivo
compose.ymlcon el contenido oficial de la documentación de Komodo. Adapta las variablesKOMODO_HOST(tu dominio),KOMODO_PASSKEY(una cadena aleatoria larga) y las rutas de volúmenes según tu configuración.Iniciar el Core
docker compose up -dVerifica que los contenedores
komodo-coreykomodo-mongoestén en estadoUp:docker compose psEl Core escucha por defecto en el puerto 9120. Si usas un reverse proxy (nginx, Caddy), crea un vhost que haga proxy hacia
localhost:9120.Configurar HTTPS con Caddy o nginx
Con Caddy (el más sencillo):
komodo.your-domain.com { reverse_proxy localhost:9120 }Caddy renueva automáticamente el certificado Let's Encrypt. Con nginx, crea un bloque
serverestándar conproxy_pass http://127.0.0.1:9120;y gestiona el certificado con Certbot.Añadir tus servidores (agentes Periphery)
En cada servidor a supervisar, despliega el agente Periphery:
docker run -d \ --name komodo-periphery \ --restart unless-stopped \ -v /var/run/docker.sock:/var/run/docker.sock \ ghcr.io/moghtech/komodo-periphery:latestEn la interfaz del Core, añade el servidor con su IP y la passkey compartida. El agente reporta inmediatamente el estado de todos los contenedores y stacks.
Conectar un repositorio Git para GitOps
En Komodo, ve a Resources → Repos y añade tu repositorio (GitHub, Gitea, Forgejo o cualquier servidor Git compatible). Luego crea un Stack apuntando a una ruta
compose.ymlen ese repositorio. En cada sincronización (manual o disparada por un webhook), Komodo aplica el diff — exactamente el comportamiento GitOps esperado.Para mayor integración con Forgejo/Woodpecker, consulta deployer-avec-portainer para la referencia de configuración de reverse proxy y SSL, aplicable a cualquier gestor de contenedores.
Comparativa: Dockge, Coolify y Komodo frente a Portainer CE
Desplace la tabla
| Criterio | Dockge | Coolify | Komodo |
|---|---|---|---|
| Licencia | MIT | Apache 2.0 | GPL-3.0 |
| Multi-servidor | No (1 host) | Sí (nodos SSH) | Sí (Core/Periphery) |
| GitOps / sync repositorio | No | Sí (push-to-deploy) | Sí (Git Stacks) |
| SSL automático | No (gestionado aparte) | Sí (Traefik integrado) | No (gestionado aparte) |
| RAM idle (Core) | < 50 MB | ~ 300–500 MB | < 256 MB |
| RBAC / usuarios | No | Sí | Sí |
| REST API | No | Sí | Sí |
| Caso de uso principal | Compose mono-servidor | PaaS dev/agencia | Flota Docker + GitOps |
| En catálogo ServOrbit | No | No | Sí |
Solución de problemas — errores comunes en la migración
El puerto 9000 de Portainer CE entra en conflicto con Komodo. Si mantienes Portainer en paralelo durante la migración, verifica que Komodo escuche en un puerto diferente (9120 por defecto). Modifica KOMODO_PORT en el Compose de Komodo si es necesario.
docker.sock rechazado por el agente Periphery. En algunas distribuciones (Ubuntu 22.04+), el socket pertenece al grupo docker. Añade el usuario actual a ese grupo (usermod -aG docker $USER) o ejecuta el agente con --user root — solo si entiendes las implicaciones de seguridad.
Los stacks Compose importados desde Portainer no arrancan. Portainer almacena algunas variables de entorno en su propio almacén (Secrets). Verifica que cada compose.yml migrado tenga un archivo .env completo, o declara las variables en la sección Variables de Komodo.
Coolify no encuentra el Dockerfile tras conectar Git. El campo "Build path" debe apuntar al directorio que contiene el Dockerfile, no a la raíz del repositorio si el archivo está en un subdirectorio. Verifica también que la rama configurada exista realmente en el remoto.
Dockge muestra "Compose file not found" tras un reinicio. El montaje de volumen debe apuntar al directorio padre del proyecto, no al archivo compose.yml directamente. La convención de Dockge es /opt/stacks/<nombre-del-stack>/compose.yml — respeta esta estructura.
Estrategia de migración progresiva
No cortes Portainer CE antes de validar tu alternativa. Despliega Komodo (o Dockge) en paralelo en el mismo servidor, importa tus stacks uno a uno, prueba cada despliegue y luego detén Portainer. Las dos herramientas no interfieren: Komodo accede al socket Docker sin entrar en conflicto con Portainer en un puerto diferente. Una migración en una noche para una flota de diez stacks es realista.
