Portainer vs Dokploy: which to deploy in 2026?

A bare VPS with Docker leaves you with one interface: the command line. That works for one machine, gets tedious for five, and becomes unmanageable for a team. A web interface centralises logs, image updates, environment variables and TLS certificates — without forcing you to maintain a full CI/CD pipeline from day one.

Two families compete: managers (Portainer, Yacht) that expose Docker as-is, and lightweight PaaS (Dokploy, Coolify, CapRover) that add a deployment layer — Git branches, automatic domains, Let's Encrypt certificates. The difference is not cosmetic: it determines whether your developers can deploy on their own or need SSH access.

Portainer CE (Community Edition) was the reference tool for six years. In 2026, Portainer restructured its licensing: the Community Edition is now limited to Kubernetes or has become paid (Portainer Business). Existing Portainer 2.x instances continue to run, but CE is no longer evolving.

This shift has several practical consequences. New installations looking for a free Docker interface have no clear CE roadmap. The portainer/portainer-ce:latest images still exist and update, but the community channel has lost momentum. And critically — Portainer 2.x has accumulated two CVEs scoring 9.4 that remain active on any unpatched installation.

If you are still running Portainer 2.x, the question is not whether to migrate on principle: it is whether your instance is up to date and whether the risk is acceptable.

Two CVEs affect Portainer versions 2.33.0 to 2.40.x:

CVE-2026-44848 (CVSS 9.4) — The /plugins/* endpoints are not protected by authentication. An unauthenticated attacker can query and modify the Docker plugins on your host via the Portainer API.

CVE-2026-44849 (CVSS 9.4) — The Swarm restrictions mechanism can be bypassed: a Portainer user with reduced rights can perform actions normally reserved for administrators on a Swarm cluster.

Fixed versions: 2.33.8, 2.39.2, 2.41.0.

To check your version:

docker exec portainer /app/portainer --version

To update:

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

If you are below 2.33.8 or 2.39.2 depending on your branch, update before continuing to use the instance. Portainer exposed on the internet without this patch is a direct intrusion vector into your Docker host.

Dokploy is not without vulnerabilities. CVE-2026-45631 (CVSS 10.0) affects versions prior to 0.29.13: an authentication secret was hardcoded in the source code, allowing anyone who knew this secret to authenticate on any Dokploy instance.

This CVE is fixed since version 0.29.13. To check and update:

# Check the installed version
docker exec dokploy dokploy --version

# Update via the official script
curl -sSL https://dokploy.com/install.sh | sh

Dokploy uses BETTER_AUTH_SECRET as a session key. On an installation prior to 0.29.13, this value was static in the code. After updating, verify your Dokploy docker-compose.yml declares a strong random value:

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

If the variable is empty or missing, generate a new value and restart:

export BETTER_AUTH_SECRET=$(openssl rand -hex 32)

Both tools run on Docker. Dokploy requires slightly more resources as it bundles a PostgreSQL database and a Traefik proxy alongside the main service.

Staying on Portainer 2.x makes sense in three situations: you already manage a Docker Swarm or Kubernetes cluster with complex configurations; you have teams that know the interface well with documented runbooks; or you need the level of detail on networks and volumes that Portainer exposes natively.

In these cases, the non-negotiable requirement is being on a patched version (2.33.8, 2.39.2 or 2.41.0) and restricting access to the interface: never expose port 9000/9443 directly on the internet, place Portainer behind a reverse proxy with additional authentication if non-admin users access it.

Migrating to Dokploy is the right decision if: you are starting fresh on a new VPS; you want developers to deploy from Git without SSH; you manage multiple domains and do not want to maintain Nginx/Traefik manually; or you are looking for an alternative after the CE 3.0 change for your Docker use case.

Portainer — interface unreachable after update
Verify that the portainer_data volume is properly mounted. An update without a named volume starts from an empty base and prompts for admin account creation again.

Portainer — TLS handshake error on port 9443
Portainer generates a self-signed certificate. Your browser warns you correctly. Place Portainer behind a reverse proxy (nginx, Caddy) with a real certificate for secure production access.

Dokploy — Traefik not generating a certificate
Most common cause: DNS has not yet propagated to the VPS. Check with dig +short your-domain.com. Traefik waits for a valid DNS response before starting the ACME challenge. If DNS is correct, verify port 80 is open (ufw allow 80).

Dokploy — Git deployment failing silently
Check the service logs in the interface (Deployments → Logs tab). The most common error is a missing BETTER_AUTH_SECRET or an SSH key not configured for private repositories. Dokploy offers a Generate SSH Key button in the project settings for private GitLab/GitHub repositories.