Home · About · Services · Industries · Projects · Products · Process · Blog · FAQ · Contact
Dokploy vs Coolify vs CapRover: picking a self-hosted PaaS in 2026 How Dokploy, Coolify and CapRover differ in runtime, proxy, builds, backups and multi-server support, and which one we would choose for different teams.
A common starting point: three or four apps on a single VPS, each started by hand with docker run or a Compose file, NGINX configs copied between folders, and certificates renewed by a cron job someone wrote two years ago. The team wants push-to-deploy and a dashboard, without paying a managed platform per app. The shortlist almost always comes down to Dokploy, Coolify and CapRover.
The short answer: pick Coolify if you want the widest catalogue of one-click services and a polished multi-server dashboard. Pick Dokploy if you want Docker Compose and Swarm to stay first-class, with database and volume backups built in. Pick CapRover only if you already run it or want the simplest, slowest-moving option. All three are open source and free to self-host.
We run Dokploy on VPS servers ourselves, so this comparison focuses on how the three differ in day-to-day operation, not just feature lists.
What all three actually do Underneath, each tool is the same idea. A control panel runs in a container on your server. It talks to the Docker daemon, builds or pulls images, starts containers, and writes reverse proxy configuration so that a domain points at the right container with a Let's Encrypt certificate. Each one gives you:
Git-based deploys from GitHub, GitLab or a generic webhook, with build logs in the browser. Automatic HTTPS through Let's Encrypt, including renewal. Environment variables per app, kept out of the repository. One-click templates for common software such as PostgreSQL, Redis, n8n, MinIO or Plausible. The ability to add more servers later, so the panel is not tied to one machine. None of them is a managed service. You still own the operating system, the firewall, the disk and the backups. That point matters more than any feature difference, and we come back to it at the end.
How they differ under the hood The differences that affect you in production are the container runtime, the reverse proxy, how builds work and what happens to your data.
Runtime: Dokploy initialises Docker Swarm on install and runs applications as Swarm services, while Compose projects can run as plain Compose or as a stack. Coolify runs plain Docker containers and Compose by default; Swarm support exists but is still described as experimental. CapRover is built entirely on Swarm. Reverse proxy: Dokploy uses Traefik. Coolify uses Traefik by default and lets you switch to Caddy. CapRover uses NGINX and lets you edit the generated config per app, which suits teams who already think in NGINX. Build types: Dokploy supports Dockerfile, Nixpacks, Railpack, Heroku and Paketo buildpacks, and static sites. Coolify supports Dockerfile, Nixpacks, Docker Compose, static sites and prebuilt images. CapRover builds from a captain-definition file that points at a Dockerfile, or deploys a prebuilt image. Database backups: Dokploy and Coolify both schedule database dumps to S3-compatible storage from the UI, and Dokploy can also back up named volumes. CapRover backs up its own configuration but leaves application data to you. Multi-server: Coolify was designed around managing many servers over SSH from one panel. Dokploy can deploy to remote servers and join nodes to a Swarm cluster. CapRover scales by adding Swarm worker nodes. Pull request previews: Dokploy and Coolify can spin up a preview deployment per pull request through the GitHub integration. CapRover has none. Install is a one-liner for all three. Run each on a fresh Ubuntu or Debian server, never on a box already serving traffic on ports 80 and 443.
# Dokploy: dashboard on port 3000
curl -sSL https://dokploy.com/install.sh | sh
# Coolify: dashboard on port 8000
curl -fsSL https://cdn.coollabs.io/coolify/install.sh | sudo bash
# CapRover: dashboard on port 3000, then finish setup from your laptop
docker run -p 80:80 -p 443:443 -p 3000:3000 -e ACCEPT_TERMS=true \
-v /var/run/docker.sock:/var/run/docker.sock \
-v /captain:/captain caprover/caprover
npm install -g caprover && caprover serversetupGive each panel a domain with HTTPS as soon as it is up, then close the raw dashboard port at the firewall. A login page on plain HTTP with an IP address is the first thing scanners find.
When Dokploy is the right choice Dokploy suits teams whose apps are already described as Dockerfiles or Compose files and who want the platform to stay out of the way. Compose projects deploy largely as written, which means the same file runs on a laptop, in CI and on the server. Because applications run as Swarm services, a crashed container is rescheduled automatically, and moving to a small multi-node cluster later does not require a new tool.
The things to know: builds run on the same server as your apps by default, so a large frontend build can starve production on a small VPS. We either build images in GitHub Actions and let Dokploy pull them, or point builds at a separate build server. Saving an environment variable does not restart the app; the new value applies on the next deploy. We covered both in more detail in our post on self-hosting with Dokploy.
When Coolify is the right choice Coolify has the largest community and the broadest template library of the three, so if your plan involves running a lot of off-the-shelf open-source software alongside your own apps, it saves the most time. Its multi-server model is also the most natural: you add servers over SSH and choose which server each resource deploys to, with one panel for all of them. Plain Docker under the hood means fewer surprises for people who have never touched Swarm.
The trade-offs: Coolify connects to every managed server, including the one it runs on, over SSH, and expects root or a user with passwordless sudo. Treat the Coolify host as a high-value target, because whoever controls it controls every server it manages. It releases often, and some releases have needed manual fixes, so test updates on a non-critical instance before upgrading the one running production. Without Swarm, a container that dies is restarted by Docker's restart policy on the same host, not moved elsewhere.
When CapRover is the right choice CapRover is the oldest of the three and the most conservative. It is a reasonable fit for a team that already runs it happily, or for simple stateless apps where the familiar NGINX layer and the captain-definition workflow are enough. Its CLI deploy from a developer's machine is still one of the simplest flows available.
For a new setup in 2026 we would rarely start here. Development is slower than the other two, there is no scheduled database backup in the UI, no pull request previews, and the one-click app catalogue is maintained by the community with uneven upkeep. It also requires a wildcard DNS record for its root domain before setup completes, which catches people who expected to add domains one by one.
What none of them does for you A self-hosted PaaS replaces a pile of shell scripts. It does not replace server administration. On every one of these platforms, the following is still your job:
Patching the host operating system and Docker, and rebooting when the kernel needs it. Firewall rules, SSH hardening and keeping the dashboard off the public internet where possible, for example behind a VPN such as Tailscale. Updating the panel itself. These panels have all shipped security fixes, and an exposed, outdated panel with Docker socket access is a full server compromise. Monitoring from outside the server. The built-in metrics cannot tell you the machine is unreachable. Backing up uploaded files, volumes and the panel's own configuration, then restoring them somewhere else to prove it works. Disk space. Old images and build cache fill disks quietly; schedule docker system prune or use the panel's cleanup setting. Lock-in is low but not zero. Your apps are containers, so they move. What does not move is the panel's own state: domains, environment variables, backup schedules and template configuration. We keep a Compose file for every app in its repository, even when the panel could generate one, so that moving between Dokploy and Coolify is a matter of hours, not a rebuild.
services:
web:
image: ghcr.io/example/web:1.4.2
restart: unless-stopped
env_file: .env
mem_limit: 512m
healthcheck:
test: ["CMD", "wget", "-qO-", "http://localhost:3000/health"]
interval: 30s
timeout: 5s
retries: 3A file like this, with a pinned image tag, restart policy, memory limit and health check, moves between Dokploy and Coolify with only the domain settings changing. If Dokploy deploys it as a Swarm stack, put the limit under deploy.resources.limits.memory instead, because stack mode ignores mem_limit. CapRover does not deploy Compose files, but the same image, variables and limits map directly onto a CapRover app.
A checklist for choosing Mostly your own apps, written as Dockerfiles or Compose, possibly growing to a few nodes: Dokploy. Many off-the-shelf services plus your apps, spread across several servers from one panel: Coolify. An existing CapRover install that works, with stateless apps: keep it, but add your own database backups. Size the server for builds, not just runtime. Both Dokploy and Coolify document 2 GB of RAM and 30 GB of disk as a minimum; we would start at 4 GB if builds run on the same box. Decide before day one where database backups go and how you will test a restore. Put the dashboard behind HTTPS and, ideally, a VPN. Keep Compose files in Git so the panel is replaceable. If you are running payment flows, patient data or anything with strict uptime expectations on a single VPS, the platform choice matters less than the operational routine around it. That is the point to get a second pair of eyes on the setup before it carries real traffic.
Infigini IT Services · 11 Kanwali Road, Dehradun 248001, India · info@infigini.com · +91 95684 87789