DevOps

Portainer vs Yacht vs Dockge: GUI para Docker en 2026

Portainer vs Yacht vs Dockge: GUI para Docker en 2026

Si ya corres Docker en tu servidor y quieres una interfaz web para no estar pegado a la terminal, estas tres opciones cubren todo el espectro: una pesada y completa, una intermedia, y una minimalista que solo entiende Docker Compose.

—

TL;DR — Lo que vas a tener al final

  • Tiempo de setup: 1-2 horas para el primer multi-stage, 30 min para los siguientes.
  • Requisitos: Docker 24+ con BuildKit habilitado.
  • Resultado: Imágenes 80-95% más pequeñas, builds 50-70% más rápidos.
  • Troubleshooting: DOCKER_BUILDKIT=1, dive para analizar layers, troubleshooting sin shell con stage debug.

Por qué necesitas una GUI para Docker

Docker funciona perfecto desde la línea de comandos, pero a medida que sumas contenedores se vuelve repetitivo: ver logs, reiniciar servicios, inspeccionar volúmenes, actualizar imágenes. Una GUI no reemplaza al CLI, pero te ahorra tecleo y te da visibilidad de un vistazo de qué está corriendo, qué se cayó y cuánto consume.

En el ecosistema open source 2026 hay tres nombres que aparecen una y otra vez en foros y subreddits de self-hosting:

  • Portainer: el veterano. Multi-host, Kubernetes, Swarm, RBAC. Más pesado, pero el más completo.
  • Dockge: del autor de Uptime Kuma (louislam). Solo entiende compose.yaml, y por eso mismo es el más fácil de usar.
  • Yacht: minimalista, pensado para un único servidor casero. Actividad de desarrollo más lenta.

La elección correcta depende de qué quieres administrar y cuántos hosts tienes. Vamos uno por uno.

—

Qué hace cada uno (en una línea)

Portainer Dockge Yacht
Foco Multi-host, enterprise, K8s Solo Docker Compose Home server único
Compose Sí, con env-var substitution Sí, archivo real en disco Sí
Kubernetes Sí No No
Swarm Sí No No
Multi-host Sí (agentes) No No
Auth Usuarios + RBAC (BE) Single-user Single-user
API REST Sí, completa No oficial Limitada
RAM en reposo ~80-150 MB ~30-50 MB ~40-70 MB
Curva Empinada al principio Plana Plana

—

Portainer: el peso pesado que sigue siendo la referencia

Portainer existe desde 2017 y pasó por varios cambios de modelo (Community Edition vs Business Edition). La rama 2.21 — publicada en 2024 — fue adoptada en 2025 como la primera línea LTS oficial, y la release notes muestra que el ciclo mensual sigue activo: workflow details, GPU visibility, mejoras en Edge environments para CE.

Lo que lo distingue:

  • Múltiples environments: conectas Portainer a varios hosts Docker (o a un cluster Swarm/K8s) y los manejas desde la misma UI. Cada environment tiene su icono y su estado.
  • Stacks con variables de entorno: importas un docker-compose.yml, defines las env vars en la UI, y Portainer hace el deploy. Después puedes editar y redeploy sin tocar el archivo original.
  • Control de acceso granular: en CE tienes usuarios y equipos básicos. En BE hay RBAC fino (por environment, por recurso, por acción).
  • API REST documentada: todo lo que haces en la UI lo puedes hacer por API, lo cual sirve para scripts de deploy y para integrar con GitOps.

El precio de todo eso es memoria. Un Portainer recién levantado consume entre 80 y 150 MB de RAM según la cantidad de environments configurados. En una Raspberry Pi con 1 GB eso es mucho. En un homelab con 4 GB ni se nota.

Cuándo elegir Portainer: tienes más de un host, vas a sumar Kubernetes pronto, o quieres una API REST para automatizar.

—

Dockge: el minimalismo hecho bien

Dockge es del mismo autor que Uptime Kuma (louislam), y se nota la filosofía: hacer una cosa, hacerla bien, y que la UI no te haga preguntas innecesarias. Su única responsabilidad es administrar archivos compose.yaml que viven en una carpeta de tu disco.

El detalle clave es ese: el archivo es real. No está escondido en una base de datos de Portainer. Lo editas, lo commiteas con git, lo mueves, lo borras — Dockge lo ve y lo trata como corresponde. Esto es ideal si vienes del mundo CLI y quieres una GUI que no opaque lo que pasa debajo.

Otras cosas que hace bien:

  • Editor interactivo de compose: con syntax highlighting y validación en vivo. Si tu YAML está roto, no te deja guardar.
  • Web terminal por container: click derecho → Terminal, y caes directo en una shell dentro del container. Sin docker exec ni SSH.
  • Update All: un botón que recorre todas tus stacks, ejecuta docker compose pull para bajar imágenes nuevas y luego hace up -d para recrear los containers que cambiaron. Útil para mantener un homelab al día sin escribir un script.
  • Multi-host vía instancias separadas: Dockge se instala por host; no hay modo multi-host unificado en una sola UI. Si necesitas ver varios hosts a la vez, eso es territorio de Portainer.

El costo en RAM es bajo: entre 30 y 50 MB en reposo. La interfaz es reactiva, se siente rápida incluso en una Raspberry Pi 4.

Cuándo elegir Dockge: administras un solo host, vives en docker-compose, y quieres una UI que no te complique la vida.

—

Yacht: el GUI que se quedó en el tiempo

Yacht fue popular cuando salió (2022) porque ofrecía algo que Portainer no: una UI limpia, sin docenas de menús, con templates de aplicaciones para instalar en un click. Era la opción obvia para alguien con un home server que quería self-hosting rápido.

El problema es el desarrollo. Mirando el repo y los issues, Yacht tuvo su último release importante hace años y el proyecto está en un rewrite en progreso que lleva más tiempo del esperado. Sigue siendo utilizable para lo básico (start/stop/restart, ver logs, inspeccionar containers), pero no recibe features nuevas al ritmo del ecosistema.

Lo que ofrece hoy:

  • Templates de apps one-click: una galería con Plex, Nextcloud, Jellyfin y otros, configurable por URL. Instalas en dos clicks.
  • UI simplificada: menos opciones que Portainer, todo a un click. Apropiado para principiantes.
  • Single-user auth: hay login, pero no hay roles ni RBAC. Si lo expones a internet, haz SSO o un reverse proxy con auth.

Lo que no ofrece:

  • Kubernetes ni Swarm
  • Multi-host
  • API REST pública
  • Mantenimiento activo al ritmo de Portainer o Dockge

Cuándo elegir Yacht: si ya lo tienes instalado y funciona, no hay razón urgente para migrar. Si estás empezando de cero en 2026, Dockge te da la misma simplicidad con un proyecto más vivo.

—

Instalación: los tres en 5 minutos con Docker Compose

Los tres se instalan como un container más. Acá van los compose files mínimos para que arranques hoy mismo.

Portainer


# Crear volumen para datos
docker volume create portainer_data
# Levantar Portainer
docker run -d 
  -p 9000:9000 
  -p 9443:9443 
  --name portainer 
  --restart=always 
  -v /var/run/docker.sock:/var/run/docker.sock 
  -v portainer_data:/data 
  portainer/portainer-ce:lts

portainer/portainer-ce:lts apunta a la rama 2.21 LTS. Si quieres bleeding edge, usa :latest que te da la versión mensual.

Después de levantar, abrí https://tu-servidor:9443, creas el usuario admin y seleccionas el environment local Docker. Si te aparece “404 Not Found” al cargar el environment, casi siempre es que el socket de Docker no montó bien. Verifica con docker exec portainer ls /var/run/docker.sock.

Dockge

Dockge necesita una carpeta de stacks persistente. La convención es /opt/stacks:


# Crear directorios
mkdir -p /opt/stacks /opt/dockge
cd /opt/dockge
# Descargar el compose oficial (puerto 5001, stacks en /opt/stacks)
curl "https://dockge.kuma.pet/compose.yaml?port=5001&stacksPath=%2Fopt%2Fstacks" 
  --output compose.yaml
# Arrancar
docker compose up -d

El archivo descargado tiene este aspecto (lo confirmas antes de levantar):


services:
  dockge:
    image: louislam/dockge:1
    restart: unless-stopped
    ports:
      - 5001:5001
    volumes:
      - /var/run/docker.sock:/var/run/docker.sock
      - ./data:/app/data
      - /opt/stacks:/opt/stacks
    environment:
      - DOCKGE_STACKS_DIR=/opt/stacks

Accedes en http://tu-servidor:5001. La primera vez te pide crear usuario. Si los stacks no aparecen: revisa que DOCKGE_STACKS_DIR apunte al mismo path que el bind mount (ambos lados de los :).

Yacht


services:
  yacht:
    image: selfhostedpro/yacht
    volumes:
      - yacht-config:/config
      - /var/run/docker.sock:/var/run/docker.sock
    ports:
      - 8000:8000
    restart: unless-stopped
volumes:
  yacht-config:

Accedes en http://tu-servidor:8000. La primera vez te pide crear el admin y listo.

—

Cómo elegir (mi recomendación honesta)

Después de probar los tres en distintos servidores, el criterio que mejor funciona es responder dos preguntas:

  • ¿Cuántos hosts Docker vas a administrar?
  • ¿Vas a usar Kubernetes o Swarm?

Si la respuesta a cualquiera es “más de uno” o “sí”, Portainer. Es la única de las tres que tiene esos casos cubiertos sin hacks.

Si administras un solo host y tu stack vive en docker-compose.yml, Dockge. Es la combinación correcta de simpleza y potencia, y el proyecto está activo.

Yacht queda para casos puntuales: tienes una Raspberry Pi con 512 MB de RAM donde Portainer no entra y quieres una UI más linda que la línea de comandos. Pero si puedes elegir, Dockge.

—

Troubleshooting común

Algunos errores que vas a ver sí o sí la primera vez:

“Permission denied” sobre /var/run/docker.sock

El socket de Docker por defecto es root-only. Si tu usuario no está en el grupo docker, ninguno de los tres GUIs puede hablarle al daemon.


# Agregar tu usuario al grupo docker
sudo usermod -aG docker $USER
# Aplicar sin re-loguear
newgrp docker
# Verificar
docker ps

Si docker ps lista containers sin sudo, estás listo. Si no, cierra sesión y vuelve a entrar — el cambio de grupo necesita un login fresco para propagarse a todos los shells.

El container del GUI reinicia en loop

Nueve de cada diez veces es un problema de volumen. Montaste una carpeta que no existe en el host, o el path dentro del container está mal.


# Ver los últimos logs del container
docker logs --tail 50 nombre-del-gui
# Verificar que el path existe en el host
ls -la /opt/stacks

Si el log dice algo tipo bind: mount failed: does not exist, es el segundo caso: crea la carpeta antes de levantar el container.

La UI carga pero no lista containers

El socket está montado pero el daemon dentro del container no tiene permisos para hablarle. En sistemas con SELinux o AppArmor activos (Fedora, RHEL, algunos Debian hardened) suele pasar.


# Diagnóstico rápido: ver el SELinux label del socket
ls -lZ /var/run/docker.sock
# Workaround para SELinux: usar :z en el bind mount
# (esto re-labelea el volumen compartido)
docker run -v /var/run/docker.sock:/var/run/docker.sock:z ...

El :z al final del bind mount le dice a SELinux que el contenido es compartido entre containers. Sin esto, el daemon de Portainer/Dockge/Yacht ve el socket pero no puede escribir.

—

Conclusión

El mejor GUI para Docker es el que no te hace perder tiempo. Para la mayoría de homelabs y servidores chicos en 2026, Dockge cumple eso mejor que las alternativas: UI limpia, archivo compose real en disco, bajo consumo, y un proyecto activo. Si tus necesidades son más grandes (multi-host, Kubernetes, API REST para automatizar), Portainer sigue siendo el estándar. Yacht se mantiene como opción legacy para setups muy chicos, pero su ritmo de desarrollo lo hace una elección riesgosa para algo nuevo.

Mi sugerencia: instala Dockge, mueve tus stacks a /opt/stacks, y si un día necesitas más, migra a Portainer. El archivo compose.yaml es el mismo.

—

Preguntas frecuentes

¿Por qué Portainer vs Yacht vs Dockge: GUI para Docker en 2026 es relevante para sysadmins Linux?

Forma parte del flujo diario de administración. Los conceptos explicados se aplican directamente a servidores en producción y resuelven problemas reales que enfrentan sysadmins hispanohablantes.

¿Qué necesito para empezar con Portainer vs Yacht vs Dockge:?

Distribución Linux actualizada (Debian, Ubuntu, RHEL, Fedora o Arch), acceso root, y conexión a internet. Para producción: entorno de staging separado antes de aplicar cambios.

¿Cuáles son los errores más comunes con Portainer vs Yacht vs Dockge:?

Los tres más frecuentes: (1) saltar la lectura de logs, (2) aplicar cambios directos en producción sin probar, (3) olvidar permisos y ownership. La documentación y un plan de rollback siempre.

¿Cuándo usar Portainer vs Yacht vs Dockge: y cuándo una alternativa?

Esta solución es ideal para el caso descrito. Alternativas como Docker, Ansible o configuración manual pueden ser mejores según contexto: portabilidad, escala y reproducibilidad son los factores clave.

¿Cómo migro desde una configuración previa a Portainer vs Yacht vs Dockge:?

Documentar el estado actual, probar la nueva configuración en staging, validar funcionalmente, y aplicar en producción con rollback plan listo. Los posts de SoyLinux incluyen troubleshooting para los problemas más comunes.

Lee también

Alfonso Moreno | Sysadmin Senior

Soy Alfonso, sysadmin senior con RHCE y más de 10 años administrando sistemas Linux para empresas y proyectos personales. Me especializo en infraestructura, redes, virtualización, monitoring, automation y self-hosting. Sobre SoyLinux.com SoyLinux.com es un blog técnico en español sobre Linux, software libre y self-hosting. Lo mantengo en mi tiempo libre. Áreas de expertise - Linux server administration: RHEL, CentOS, Rocky, Alma, Fedora, Debian, Ubuntu - Network services: Postfix, BIND, Samba, NFS, Squid - Virtualización y containers: KVM, Proxmox, Docker, Podman - Monitoring: Prometheus, Grafana, Zabbix - Automation: Ansible, Bash scripting - Self-hosting: Vaultwarden, Nextcloud, Jellyfin, Immich, Homelab Contacto - Email: [email protected]

Deja una respuesta

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *