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 years. With Portainer 3, the vendor ended the Community Edition: Portainer 3 has no CE edition, and CE 2.45 is the last Community release. Portainer 3 ships as Business Edition (free for up to three nodes with the "3 Nodes Free" licence), puts Kubernetes first for new features and keeps Docker, Swarm and Podman. CE 2.45 instances keep running and receive the 2.45 LTS fixes until August 2027, but no new features.

This shift has several practical consequences. New installations looking for a free Docker interface have no CE roadmap. The portainer/portainer-ce images still exist and receive fixes from the 2.45 branch, but will not evolve further. And critically — Portainer 2.x has accumulated critical flaws, including two CVEs scoring 9.4, which remain exploitable 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 every Portainer branch up to the fixed versions below (versions before 2.33.0 are end-of-life and will not be fixed):

CVE-2026-44848 (CVSS 9.4) — The /plugins/* endpoints of the Docker API proxied by Portainer bypass authorization checks. A standard (non-admin) user with access to a Docker environment can install and enable a Docker plugin, which runs as root on your host.

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. Further critical flaws have been published since, fixed in 2.45.2 and 2.45.3 and with no fix on the 2.39 branch: target 2.45.3 LTS, the latest release as of 7 November 2026.

To check your version:

docker exec portainer /portainer --version

To update:

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

If you are below 2.45.3, update before continuing to use the instance. This command publishes the interface on 127.0.0.1 only: reach it through an SSH tunnel (ssh -L 9443:127.0.0.1:9443 user@your-vps, then https://localhost:9443) or a reverse proxy. Add -p 8000:8000 only if you use Edge agents. Portainer exposed on the internet without patches is a direct intrusion vector into your Docker host.

Dokploy is not without vulnerabilities. CVE-2026-45631 (CVSS 10.0) affected default installations prior to 0.29.3: when the BETTER_AUTH_SECRET variable was not set — and the install script did not set it — the code fell back to a hardcoded value, identical on every instance. Anyone could forge a token and take over the administrator account, without authentication.

The fix landed in 0.29.3, together with a migration script to run after updating. Many other critical flaws (command injections, missing access controls) were fixed up to 0.29.13: do not stay below it, and target the latest release (0.31.0 as of 7 November 2026). To check and update:

# Check the installed version (service image tag)
docker service inspect dokploy --format '{{.Spec.TaskTemplate.ContainerSpec.Image}}'

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

Since 0.29.3, Dokploy reads BETTER_AUTH_SECRET from a Docker secret (BETTER_AUTH_SECRET_FILE variable). After updating, check that the service uses it:

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

If the line is missing, run the official security script published with 0.29.3: it generates a unique secret and updates the service.

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

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 an up-to-date version (2.45.3 as of 7 November 2026) 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 end of CE (Portainer 3 has no Community Edition) 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). On a private repository, a frequent cause is a missing SSH key, or one not authorised on the repository. Dokploy lets you create one in Settings → SSH Keys (Create SSH Key button), to add as a deploy key on the repository; for GitHub, GitLab, Gitea or Bitbucket, you can also connect the provider in Dokploy's Git settings.