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 años. Con Portainer 3, el editor puso fin a la edición Community: Portainer 3 no tiene edición CE, y CE 2.45 es la última versión Community publicada. Portainer 3 se distribuye como Business Edition (gratuita hasta tres nodos con la licencia «3 Nodes Free»), da prioridad a Kubernetes para las nuevas funciones y mantiene Docker, Swarm y Podman. Las instancias CE 2.45 siguen funcionando y reciben los parches de la 2.45 LTS hasta agosto de 2027, pero ninguna función nueva.

Este cambio tiene varias consecuencias prácticas. Las nuevas instalaciones que buscan una interfaz Docker gratuita no encuentran hoja de ruta para CE. Las imágenes portainer/portainer-ce siguen existiendo y recibiendo los parches de la rama 2.45, pero ya no evolucionarán. Y de forma crítica — Portainer 2.x ha acumulado fallos críticos, entre ellos dos CVEs con puntuación 9.4, que siguen siendo explotables 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 todas las ramas de Portainer hasta las versiones corregidas indicadas abajo (las versiones anteriores a 2.33.0, sin soporte, no se corregirán):

CVE-2026-44848 (CVSS 9.4) — Los endpoints /plugins/* de la API Docker que Portainer reenvía escapan al control de autorización. Un usuario estándar (no administrador) con acceso a un entorno Docker puede instalar y activar un plugin Docker, que se ejecuta como root en tu host.

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. Desde entonces se han publicado otros fallos críticos, corregidos en 2.45.2 y 2.45.3 y sin parche en la rama 2.39: apunta a la 2.45.3 LTS, última versión publicada a 7 de noviembre de 2026.

Para verificar tu versión:

docker exec portainer /portainer --version

Para actualizar:

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

Si estás por debajo de 2.45.3, actualiza antes de seguir usando la instancia. Este comando solo publica la interfaz en 127.0.0.1: accede mediante un túnel SSH (ssh -L 9443:127.0.0.1:9443 user@tu-vps, luego https://localhost:9443) o un proxy inverso. Añade -p 8000:8000 solo si usas agentes Edge. Portainer expuesto en internet sin parches es un vector de intrusión directo en tu host Docker.

Dokploy tampoco está exento de vulnerabilidades. CVE-2026-45631 (CVSS 10.0) afectaba a las instalaciones por defecto anteriores a 0.29.3: cuando la variable BETTER_AUTH_SECRET no estaba definida — y el script de instalación no la definía —, el código recurría a un valor hardcoded, idéntico en todas las instancias. Cualquiera podía falsificar un token y tomar la cuenta de administrador, sin autenticación.

La corrección llegó en 0.29.3, junto con un script de migración que se ejecuta tras actualizar. Muchos otros fallos críticos (inyecciones de comandos, controles de acceso ausentes) se corrigieron hasta la 0.29.13: no te quedes por debajo y apunta a la última versión (0.31.0 a 7 de noviembre de 2026). Para verificar y actualizar:

# Verificar la versión instalada (tag de la imagen del servicio)
docker service inspect dokploy --format '{{.Spec.TaskTemplate.ContainerSpec.Image}}'

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

Desde 0.29.3, Dokploy lee BETTER_AUTH_SECRET desde un secreto Docker (variable BETTER_AUTH_SECRET_FILE). Tras actualizar, verifica que el servicio lo usa:

docker service inspect dokploy --format '{{range .Spec.TaskTemplate.ContainerSpec.Env}}{{println .}}{{end}}' | grep BETTER_AUTH_SECRET_FILE

Si la línea no aparece, ejecuta el script de seguridad oficial publicado con la 0.29.3: genera un secreto único y actualiza el servicio.

curl -sSL https://dokploy.com/security/0.29.3.sh | bash

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 actualizada (2.45.3 a 7 de noviembre de 2026) 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 fin de CE (Portainer 3 no tiene edición Community) 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). En un repositorio privado, una causa frecuente es una clave SSH ausente o no autorizada en el repositorio. Dokploy permite crear una en Settings → SSH Keys (botón Create SSH Key), para añadirla como clave de despliegue del repositorio; para GitHub, GitLab, Gitea o Bitbucket, también puedes conectar el proveedor en los ajustes Git de Dokploy.