Dokploy vs Coolify vs CapRover: Which Self-Hosted PaaS Should You Run in 2026?

Every one of these tools promises the same thing: your own Heroku on a ₹500-a-month VPS. Push to Git, get a deployed app with HTTPS, a database and logs, with no AWS bill and no Kubernetes.
I run my own stack this way. My portfolio frontend, its ASP.NET Core API, Postgres and a few side projects all sit on one VPS behind Dokploy. Before choosing, I looked closely at Coolify and CapRover too. This post is the comparison I wanted back then: how each one deploys, where each one hurts, and which one to pick depending on who you are.
What's inside
- The short answer
- What a self-hosted PaaS actually does
- Dokploy
- Coolify
- CapRover
- Side-by-side comparison
- What I run, and the gotchas I hit
- Common mistakes
- Which one should you pick?
- FAQ
1. The short answer
- Dokploy if you think in Docker Compose, want a clean, fast dashboard, and like database backups to S3 built in.
- Coolify if you want the biggest catalogue of one-click services, preview deployments for pull requests, and don't mind a busier interface.
- CapRover if you want something simple and long-proven for straightforward single-container apps, and are happy with nginx.
All three are open source, free to self-host, and run on a single VPS with 2–4 GB of RAM for small workloads.
2. What a self-hosted PaaS actually does
A "platform as a service" hides the boring parts of running apps. A self-hosted one does it on a server you control. Under the hood, all three do roughly the same job:
- Pull your code from GitHub, GitLab or a Docker image.
- Build it with a Dockerfile, Nixpacks/buildpacks, or a Compose file.
- Run it as Docker containers.
- Route traffic through a reverse proxy (Traefik or nginx) and issue Let's Encrypt certificates automatically.
- Manage databases like Postgres, MySQL, MongoDB and Redis as one-click services.
- Show logs, metrics and deploy history in a web dashboard.
The differences are in how they do each step, and those differences decide how pleasant your day-to-day is.
3. Dokploy
Dokploy is the youngest of the three and has grown quickly.
What it does well
- Docker Compose is a first-class citizen. Paste a Compose file, and it runs as a stack. Most self-hostable software ships a Compose file, so this matters a lot.
- Traefik routing with automatic HTTPS, plus the option to drop in your own Traefik config files for anything custom.
- Database services with scheduled backups to any S3-compatible storage (AWS S3, Backblaze B2, Cloudflare R2, MinIO, RustFS).
- Multi-server and Docker Swarm support when you outgrow one box.
- A clean, quick UI and an API you can call to trigger deploys from your own code.
Where it hurts
- It's moving fast, so read the release notes before upgrading.
- The one-click template catalogue is smaller than Coolify's.
I wrote about moving my setup onto it in From hand-written nginx configs to Dokploy.
4. Coolify
Coolify is the most popular of the three and the most feature-rich.
What it does well
- A very large catalogue of one-click services: databases, analytics, CMSs, automation tools and more.
- Preview deployments per pull request, which is great for agencies showing clients work in progress.
- Manage many servers from one dashboard, including servers you add later.
- Database backups to S3-compatible storage and a choice of proxy (Traefik or Caddy).
- A paid cloud option if you want the dashboard hosted for you while apps still run on your servers.
Where it hurts
- More features means more screens and settings to learn.
- Because it covers so much, you'll occasionally hit rough edges in less-used integrations. Pin versions of the services you depend on.
5. CapRover
CapRover has been around the longest and is the simplest model of the three.
What it does well
- Simple mental model: an app is a container, deployed from a
captain-definitionfile, a Dockerfile, or an image. - nginx plus Docker Swarm for routing and clustering, both well understood.
- One-click apps for common software, and a CLI for deploying from your machine.
- Mature and stable: years of production use behind it.
Where it hurts
- Multi-service Docker Compose apps are awkward. It's built around single apps rather than stacks.
- Customising nginx means editing templates rather than adding a config file.
- The interface and feature set feel older next to Dokploy and Coolify.
6. Side-by-side comparison
| Dokploy | Coolify | CapRover | |
|---|---|---|---|
| Reverse proxy | Traefik | Traefik or Caddy | nginx |
| Docker Compose stacks | Excellent | Good | Limited |
| One-click services | Good | Largest | Good |
| Database backups to S3 | Built in | Built in | Manual / via apps |
| PR preview deploys | Yes | Yes | No |
| Multi-server | Yes (Swarm / remote servers) | Yes | Yes (Swarm) |
| Deploy API / webhooks | Yes | Yes | Yes |
| Learning curve | Low | Medium | Low |
Feature sets change quickly, especially for Dokploy and Coolify, so check each project's docs before you commit.
7. What I run, and the gotchas I hit
My production setup on one VPS:
- Frontend: an Angular site pre-rendered to static HTML and served by nginx, deployed by Dokploy.
- API: ASP.NET Core with Postgres, deployed by Dokploy.
- Extras outside Dokploy: some services that aren't really "apps" (a mail server, a WhatsApp gateway, a search engine) run as plain Docker Compose stacks on the same Docker network, so my apps reach them by container name. Dokploy's Traefik still routes their public URLs through small config files.
Three things I learned the hard way:
- Build cache can ship stale content. My backend triggers a frontend rebuild through Dokploy's deploy API when a blog post goes live. Rebuilding the same Git commit let Docker reuse a cached build layer, so the "new" site was the old one. Turning on Dokploy's Clean Cache for that app fixed it.
- API details matter. The deploy endpoint ignored my request until the
Content-Typewas exactlyapplication/json. A one-line fix, but it looked like a successful deploy that never happened. - No backups by default. The dashboard makes it easy to forget the server is a single point of failure. Configure an S3 backup destination for every database on day one, and copy backups off the server.
If you're still choosing where to put backups, I compared the options in Blob storage 101: cloud vs self-hosting.
8. Common mistakes
- Running everything on one tiny VPS. Postgres plus a few Node or .NET builds will swap on 1 GB. Start at 2–4 GB, and keep builds off production if you can.
- Using
latestimage tags. Pin versions so an upgrade happens when you choose. - Skipping off-server backups. A PaaS is not a backup strategy.
- Exposing database ports to the internet. Keep databases on the internal Docker network.
- Putting secrets in Git. Use the platform's environment variables or a secrets manager. I covered the options in Where should your secrets live?
9. Which one should you pick?
- Solo developer or indie hacker with a few apps: Dokploy. It's fast to learn, Compose-friendly, and backups are built in.
- Agency hosting many client sites: Coolify. Preview deploys and the large catalogue save real time when you're juggling projects.
- Simple single-container apps, minimal fuss: CapRover. It's proven and predictable.
Not sure? Install Dokploy and Coolify on two throwaway VPS instances for an afternoon and deploy the same app on both. You'll know within an hour which one feels right.
FAQ
Is a self-hosted PaaS production-ready?
Yes, for small and medium workloads. Many businesses run real traffic on them. You are responsible for the server: updates, monitoring and backups.
How much RAM do I need?
2 GB is a workable minimum for the platform plus a small app and database. 4 GB or more is comfortable if you build images on the same server.
Can I migrate between them?
Yes. Your apps are Docker containers and your data is in databases, so migration means redeploying containers and restoring database dumps. Domains just need their DNS pointed at the new server.
Are they really free?
All three are open source and free to self-host. Coolify and Dokploy also offer paid cloud dashboards if you'd rather not host the control panel yourself.
Do I still need Docker knowledge?
Some. You can deploy without writing Dockerfiles, but knowing how containers, volumes and networks work will save you when something breaks.
Want help setting one up?
If you'd rather not work this out alone, I offer technical consulting for exactly this: picking the platform, sizing the VPS, and getting databases, backups and monitoring right from day one.


