Portainer lo usé durante un par de años. Es una herramienta sólida, madura, y que hace cosas que Dockge no hace, como gestionar Kubernetes, gestionar nodos Docker Swarm, o tener control de acceso por roles. Si gestionas infraestructura de empresa o un cluster complejo, tiene sentido.
En un homelab personal, sin embargo, Portainer me empezó a resultar pesado. No por los recursos, que son mínimos, sino por el modelo mental. Portainer quiere gestionar tus contenedores, tus redes, tus volúmenes, tus imágenes. Tiene su propia capa de abstracción por encima de Docker. Y cuando algo no va como esperas, a veces es difícil saber si el problema está en tu configuración, en Portainer, o en Docker.
Yo trabajo con Docker Compose. Todos mis servicios son un docker-compose.yml en una carpeta. Esa es mi unidad de trabajo, no el contenedor individual. Dockge parte de exactamente esa premisa.
Qué es Dockge#
Dockge es una aplicación web creada por el mismo desarrollador de Uptime Kuma (Louis Lam). La primera versión salió a finales de 2023 y lleva desde entonces sumando usuarios en el mundo homelab.
La idea central es simple: Dockge gestiona stacks de Docker Compose. Un stack es una carpeta con un compose.yaml dentro. Dockge lee esa carpeta, muestra los stacks que existen, y te deja arrancar, parar, actualizar y editar cada uno desde el navegador.
No intenta abstraer Docker Compose por debajo. Cuando arrancas un stack desde Dockge, está ejecutando docker compose up -d en esa carpeta. Cuando lo paras, ejecuta docker compose down. Sin magia, sin estado propio que pueda desincronizarse.
Eso significa que si hago cambios por SSH directamente en los archivos, Dockge lo refleja al momento. Y si alguien usa Dockge sin que yo lo sepa, puedo ver exactamente qué cambió mirando el compose.yaml con git.
Instalación#
Dockge se instala él mismo como un stack de Docker Compose. Hay cierta simetría en eso.
Primero crear la estructura de directorios:
| |
Luego crear el compose.yaml:
| |
Arrancar:
| |
Acceder en http://ip-del-servidor:5001. La primera vez pide crear una cuenta de administrador.
La variable DOCKGE_STACKS_DIR le indica dónde están los stacks. Yo uso /opt/stacks y tengo cada servicio en una subcarpeta: /opt/stacks/vaultwarden/, /opt/stacks/gitea/, /opt/stacks/jellyfin/, etcétera.
La interfaz#
Cuando entras, ves una lista de todos los stacks en el directorio configurado. Cada stack muestra:
- Estado (running, stopped, partial)
- Número de contenedores activos
- Botones de acción: start, stop, restart, pull + restart
Al hacer clic en un stack, abres la vista de detalle. Aquí está el editor YAML integrado. Puedes modificar el compose.yaml directamente en el navegador, guardar, y Dockge aplica los cambios. Si añades un nuevo servicio al compose, lo detecta y pregunta si quieres recrear el stack.
La parte que más uso en el día a día es el log en tiempo real. Seleccionas un contenedor y ves los logs streameados directamente, sin tener que abrir una terminal y hacer docker compose logs -f servicio. Para revisar rápido si un servicio está funcionando bien después de un reinicio, es muy cómodo.
También tiene terminal interactiva. Puedes abrir una shell dentro de cualquier contenedor en ejecución desde el propio navegador. Útil para diagnósticos rápidos.
Comparación real con Portainer#
No es que Portainer sea mala herramienta, es que sirve para casos de uso diferentes.
Lo que Portainer hace que Dockge no hace:
- Gestión de Kubernetes y Swarm
- Control de acceso por usuarios y roles
- Gestión de registries privados con UI
- Templates de aplicaciones con un clic
- API REST completa para automatizar acciones
Lo que Dockge hace mejor que Portainer para mi uso:
- El editor YAML es central, no es un añadido
- Menos pasos para hacer la tarea más común (editar un compose y redeployar)
- No hay estado propio que pueda desincronizarse del estado real de Docker
- Consumo de recursos mínimo (alrededor de 20 MB de RAM)
- Instalación en dos minutos
La diferencia más notable en el día a día es la filosofía. Portainer tiene su propia jerarquía de objetos: endpoints, stacks, servicios. Cuando creas un stack en Portainer, Portainer lo registra en su base de datos. Si haces cambios fuera de Portainer, puede haber conflictos. Dockge no tiene esa capa: lo que hay en disco es la fuente de verdad.
Migrar desde Portainer#
Si ya tienes servicios corriendo gestionados por Portainer, la migración es sencilla porque en el fondo son compose files.
Desde Portainer puedes exportar el compose de cada stack. Los mueves a /opt/stacks/nombre-del-stack/compose.yaml y Dockge los detecta automáticamente. Los contenedores que ya estaban corriendo aparecen como running en Dockge sin necesidad de recrearlos.
Lo que sí tienes que hacer manualmente es revisar que los compose files exportados de Portainer tienen todas las configuraciones correctas, porque a veces Portainer guarda cosas en su propia base de datos que no están en el compose (como ciertas configuraciones de red que creaste desde la UI).
Limitaciones que hay que aceptar#
Dockge gestiona un solo servidor. Si tienes tres servidores con Docker, necesitas una instancia de Dockge en cada uno y acceder a cada una por separado. No hay vista unificada multi-host.
Para eso existe Dockge en modo agente (una funcionalidad añadida más tarde), donde puedes tener instancias remotas conectadas a una instancia principal. Pero en mi caso con tres o cuatro servidores, prefiero tener Dockge independiente en cada uno y gestionarlos por separado. El overhead cognitivo de seguir qué corre en qué máquina lo tengo asumido.
Tampoco tiene gestión de imágenes, registries, o volumes de forma directa. Para eso uso la CLI de Docker cuando lo necesito. En el 95% de los casos, lo que necesito hacer está en el compose file y Dockge lo resuelve.
Estructura de directorios que uso#
Para que Dockge funcione bien, es importante tener los stacks bien organizados. Mi estructura en /opt/stacks:
| |
Cada servicio en su propia carpeta, con un solo archivo compose.yaml. Los datos persistentes van en volúmenes nombrados o en subdirectorios como ./data dentro de la carpeta del stack. Así todo lo relacionado con un servicio está en un solo sitio.
Este esquema también facilita los backups con Restic: hago backup de /opt/stacks completo y tengo todos los compose files versionados. Los datos de las aplicaciones están en volúmenes Docker o en ./data, que también incluyo en el backup.
Poner Dockge detrás de un reverse proxy#
Para acceder a Dockge con HTTPS y sin exponer el puerto 5001 directamente, lo pongo detrás de Nginx Proxy Manager o Traefik como el resto de servicios.
Con Nginx Proxy Manager es trivial: crear un proxy host apuntando a ip-del-servidor:5001 con SSL de Let’s Encrypt. Dockge no tiene configuración especial de headers.
Con Traefik, añadir las labels correspondientes al servicio en el compose:
| |
Por qué me quedé con Dockge#
He probado varias alternativas en el último año. Yacht, que tiene un concepto similar pero con un desarrollo menos activo. Portainer Community Edition, que ya conocía. Lazydocker, que es una TUI en terminal y que no resuelve el problema de acceder desde el navegador.
Dockge gana en mi caso por la combinación de tres cosas: hace exactamente lo que necesito sin intentar hacer más, el editor YAML es central y bien hecho, y el desarrollo es activo (el repositorio de GitHub tiene releases frecuentes y el autor responde a issues).
Para un homelab con 10 a 30 servicios Docker Compose en uno o dos servidores, Dockge es difícil de superar. Si tienes una infraestructura más compleja con múltiples hosts y necesitas control centralizado, Portainer sigue siendo la opción con más funcionalidades.
En mi caso, hace meses que no echo de menos nada de lo que dejé atrás al migrar de Portainer. Si tienes el mismo tipo de setup que yo, tiene sentido probarlo. La instalación son cinco minutos y puedes tenerlos corriendo en paralelo durante el tiempo que necesites para decidir.