Portainer vs Dokploy: ¿cuál desplegar en 2026?

Un VPS con Docker te deja una sola interfaz: la línea de comandos. Es suficiente para una máquina, tedioso para cinco e inmanejable para un equipo. Una interfaz web centraliza los logs, las actualizaciones de imágenes, las variables de entorno y los certificados TLS, sin obligarte a mantener un pipeline CI/CD completo desde el primer día.

Dos familias compiten: los gestores (Portainer, Yacht) que exponen Docker tal como es, y los PaaS ligeros (Dokploy, Coolify, CapRover) que añaden una capa de despliegue — ramas Git, dominios automáticos, certificados Let's Encrypt. La diferencia no es cosmética: determina si tus desarrolladores pueden desplegar solos o necesitan acceso SSH.

Portainer CE (Community Edition) fue la referencia del sector durante seis años. En 2026, Portainer reestructuró su modelo de licencia: la edición Community queda limitada a Kubernetes o pasa a ser de pago (Portainer Business). Las instancias Portainer 2.x ya desplegadas siguen funcionando, pero CE ya no evoluciona.

Este cambio tiene varias consecuencias prácticas. Las nuevas instalaciones que buscan una interfaz Docker gratuita no encuentran una hoja de ruta clara para CE. Las imágenes portainer/portainer-ce:latest siguen existiendo y actualizándose, pero el canal comunitario ha perdido impulso. Y de forma crítica — Portainer 2.x ha acumulado dos CVEs con puntuación 9.4 que permanecen activos en cualquier instalación sin parchear.

Si todavía usas Portainer 2.x, la pregunta no es si migrar por principio: es si tu instancia está actualizada y si el riesgo es aceptable.

Dos CVEs afectan a las versiones Portainer 2.33.0 a 2.40.x:

CVE-2026-44848 (CVSS 9.4) — Los endpoints /plugins/* no están protegidos por autenticación. Un atacante no autenticado puede consultar y modificar los plugins Docker de tu host a través de la API de Portainer.

CVE-2026-44849 (CVSS 9.4) — El mecanismo de restricciones Swarm puede ser eludido: un usuario de Portainer con derechos reducidos puede ejecutar acciones normalmente reservadas al administrador en un clúster Swarm.

Versiones corregidas: 2.33.8, 2.39.2, 2.41.0.

Para verificar tu versión:

docker exec portainer /app/portainer --version

Para actualizar:

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

Si estás por debajo de 2.33.8 o 2.39.2 según tu rama, actualiza antes de seguir usando la instancia. Portainer expuesto en internet sin este parche es un vector de intrusión directo en tu host Docker.

Dokploy tampoco está exento de vulnerabilidades. CVE-2026-45631 (CVSS 10.0) afecta a las versiones anteriores a 0.29.13: un secreto de autenticación estaba hardcoded en el código fuente, permitiendo a cualquiera que conociera ese secreto autenticarse en cualquier instancia Dokploy.

Este CVE está corregido desde la versión 0.29.13. Para verificar y actualizar:

# Verificar la versión instalada
docker exec dokploy dokploy --version

# Actualizar mediante el script oficial
curl -sSL https://dokploy.com/install.sh | sh

Dokploy usa BETTER_AUTH_SECRET como clave de sesión. En una instalación anterior a 0.29.13, este valor era estático en el código. Tras actualizar, verifica que tu docker-compose.yml de Dokploy declara un valor aleatorio fuerte:

grep BETTER_AUTH_SECRET /etc/dokploy/docker-compose.yml

Si la variable está vacía o ausente, genera un nuevo valor y reinicia:

export BETTER_AUTH_SECRET=$(openssl rand -hex 32)

Ambas herramientas funcionan sobre Docker. Dokploy requiere algo más de recursos, ya que incluye una base de datos PostgreSQL y un proxy Traefik además del servicio principal.

Quedarse en Portainer 2.x tiene sentido en tres situaciones: ya gestionas un clúster Docker Swarm o Kubernetes con configuraciones complejas; tienes equipos que dominan la interfaz con runbooks documentados; o necesitas el nivel de detalle sobre redes y volúmenes que Portainer expone de forma nativa.

En estos casos, la condición innegociable es estar en una versión parcheada (2.33.8, 2.39.2 o 2.41.0) y restringir el acceso a la interfaz: nunca expongas el puerto 9000/9443 directamente en internet, coloca Portainer detrás de un proxy inverso con autenticación adicional si usuarios no administradores acceden a él.

Migrar a Dokploy es la decisión correcta si: empiezas desde cero en un VPS nuevo; quieres que tus desarrolladores desplieguen desde Git sin SSH; gestionas múltiples dominios y no quieres mantener Nginx/Traefik manualmente; o buscas una alternativa tras el cambio de CE 3.0 para tu uso con Docker.

Portainer — interfaz inaccesible tras actualización
Verifica que el volumen portainer_data esté correctamente montado. Una actualización sin volumen con nombre parte de una base vacía y vuelve a solicitar la creación de la cuenta de administrador.

Portainer — TLS handshake error en el puerto 9443
Portainer genera un certificado autofirmado. Tu navegador avisa correctamente. Coloca Portainer detrás de un proxy inverso (nginx, Caddy) con un certificado real para acceso seguro en producción.

Dokploy — Traefik no genera un certificado
Causa más frecuente: el DNS aún no se ha propagado hacia el VPS. Verifica con dig +short tudominio.com. Traefik espera una respuesta DNS válida antes de lanzar el challenge ACME. Si el DNS es correcto, verifica que el puerto 80 esté abierto (ufw allow 80).

Dokploy — despliegue Git que falla silenciosamente
Revisa los logs del servicio en la interfaz (Deployments → pestaña Logs). El error más común es un BETTER_AUTH_SECRET ausente o una clave SSH no configurada para repositorios privados. Dokploy ofrece un botón Generate SSH Key en los ajustes del proyecto para repositorios privados de GitLab/GitHub.