Self-hosted PaaS in 2026: revisit Coolify, Dokku and CapRover before you treat another VPS as a home-made Heroku

Many teams still treat a cheap VPS as a home-made Heroku. They SSH in, paste a docker-compose.yml, open ports by hand, renew certificates when something breaks, and promise to “clean this up later”. That habit works for one weekend project. It does not age well when you have five apps, two databases, and a junior engineer who should not need root every Friday.

A self-hosted PaaS sits between raw containers and a full Kubernetes cluster. You keep the servers. The platform owns the boring deploy path: build or pull an image, start the process, route a hostname, issue TLS, and give you a repeatable way to ship the next commit. This post revisits three open-source options that teams still meet when they want that path without renting a managed PaaS: Coolify, Dokku, and CapRover. The aim is not to crown a winner. The aim is to help you pick something you can operate.

What a self-hosted PaaS actually does

Before comparing tools, it helps to be clear about the job. A practical self-hosted PaaS usually covers some mix of these:

• Deploy from Git or an image: push a branch, sync a repo, upload a build context, or pull a registry image.
• Build into containers: Dockerfile, buildpacks, Nixpacks-style autodetection, or Compose definitions, depending on the tool.
• Route HTTP(S): map a hostname to a container port, and automate certificates where DNS allows it.
• Run backing services: databases and one-click apps as managed resources, not only as forgotten Compose services.
• Day-2 ops hooks: logs, restarts, env vars, volumes, backups of platform config, and sometimes database dumps.

It is not magic. You still own the OS, the firewall, DNS, disk, and restore drills. The win is that you stop reinventing the deploy script for every repo.

Coolify: dashboard control plane over your Docker servers

History and licence. The project lives at coollabsio/coolify. The repository was created in January 2021 under the coollabsio organisation. It is licensed under the Apache License 2.0. Official docs describe Coolify as an open-source, self-hostable platform for deploying applications, databases and services on servers you control. The latest stable release at the time of writing is v4.6.0 (2 November 2026).

How it works. Coolify is a control plane. You run a Coolify instance (self-hosted, or Coolify Cloud for the control plane only). That instance connects to one or more servers over SSH, prepares Docker, and coordinates builds, deployments, domains, HTTPS, health checks and day-to-day operations. Workloads remain ordinary Docker resources on your hosts. Official docs are clear that if the Coolify instance is down, already running resources keep running; you lose automation and the dashboard until it returns.

Applications can come from a Git repository, a Dockerfile, Docker Compose, or a prebuilt image. Build strategies include Nixpacks, Railpack (documented as beta), Static, Dockerfile, and Docker Compose. Traefik is the default reverse proxy with automatic TLS; Caddy is also supported. Databases are first-class resources, with scheduled backups and dashboard restore for several engines (PostgreSQL, MySQL, MariaDB, MongoDB, ClickHouse, experimental SQLite) and optional S3-compatible offload. Redis-family engines persist data but do not get that scheduled dump UI. Coolify also ships hundreds of one-click service templates (the GitHub description says 360+).

Where it is strong.

• Teams that want a full dashboard for apps, databases, domains and one-click services without learning a Heroku-style CLI first.
• Teams that need one Coolify instance to manage several servers, including separate build servers and multi-server application deploys (with the limits documented below).
• Teams that want scheduled database dumps and S3 offload without inventing cron jobs for every Postgres container.

What to watch.

• Coolify docs state that attaching extra deployment servers does not create full high availability; you still need an external load balancer, shared state and monitoring. Docker Compose apps and apps with persistent storage cannot currently use that Servers attach flow.
• Create the admin account immediately after install: anyone who reaches registration first can become instance admin with deep server access.
• Instance backups save Coolify projects and settings. They do not replace engine-aware database backups.

Dokku: git push PaaS with a plugin ecosystem

History and licence. The project lives at dokku/dokku. The repository was created in June 2013. It is licensed under the MIT License (copyright Jeff Lindsay in the LICENSE file). Dokku describes itself as a Docker-powered PaaS that helps you build and manage application lifecycle. The latest stable release at the time of writing is v0.38.34 (30 October 2026), with install docs pointing at the matching bootstrap script.

How it works. Dokku’s classic model is CLI-first on a single server. Official getting-started docs say it runs on a single server of your choice. You create an app, add an SSH key, set a global domain, and deploy with git push. Builds can use Herokuish buildpacks (default), a Dockerfile, a Docker image, or Cloud Native Buildpacks via the pack builder when a project.toml is present (or when you select that builder). Nginx routes web processes. Scaling, storage mounts, cron and plugins cover the rest.

Backing services are not included by default. Official plugins create and link datastores (for example dokku-postgres). TLS uses the built-in certificates plugin, or the optional Let’s Encrypt plugin with renewal cron. The default scheduler is docker-local; install docs also mention a K3s scheduler with higher memory needs if you choose it deliberately.

Where it is strong.

• Teams that already think in Heroku-style git push, Procfile processes and buildpacks, and prefer SSH plus CLI over a heavy dashboard.
• Long-lived plugin ecosystem for Postgres and friends, zero-downtime deploys, and fine-grained rebuild or scale commands.
• Operators who want a small, well-documented core and are comfortable scripting the rest.

What to watch.

• The default docker-local scheduler is single-server oriented. Do not assume cluster HA just because containers are involved.
• Let’s Encrypt is a plugin path, not an invisible default. Domains must point correctly first.
• Cloud Native Buildpacks need the separate pack CLI; docs list caveats around buildpack selection and cache clearing.
• Datastore plugins help, but you still own backups and restore tests.

CapRover: Docker Swarm PaaS with a web UI

History and licence. The project lives at caprover/caprover. The repository was created in October 2017. The LICENSE file states the Apache License 2.0, with an appendix that restricts modification and redistribution of paid CapRover features and requires modifications of free features to remain free and open source. GitHub’s licence API therefore reports the SPDX id as NOASSERTION; read the LICENSE and TERMS files before commercial redistribution assumptions. The latest stable release at the time of writing is v1.16.0 (3 November 2026).

How it works. CapRover manages Docker Swarm services on one or more servers. Official docs say it initialises a Swarm even for a single-node install. CapRover stores app config and deploy history; Swarm runs containers; NGINX routes HTTP(S); a registry distributes images across nodes. Apps use a captain-definition JSON file (schema version 2) pointing at a Dockerfile, inline Dockerfile lines, a language template, or a prebuilt image. Deploy from the dashboard, the CLI (caprover deploy), or automation. One-click templates create ordinary CapRover apps. HTTPS uses Certbot / Let’s Encrypt style issuance; keep port 80 reachable for HTTP-01.

Multi-node setup is documented: join workers (or managers with quorum planning), open Swarm ports between trusted nodes, and configure a default push registry before adding nodes. Persistent apps are pinned; local volumes do not follow a reschedule.

Where it is strong.

• Teams that want a Swarm-backed UI and are ready to learn CapRover’s app model rather than raw docker stack files.
• Stateless apps that may later scale across Swarm nodes once a registry and networking are in place.
• Operators who like one-click templates and a clear split between CapRover config backup and application data backup.

What to watch.

• Getting started expects a wildcard DNS record and open ports 80, 443 and 3000 during setup. Plan DNS before you install.
• Configuration backup archives /captain/data. Official backup docs state this does not automatically include Docker volumes, bind mounts elsewhere, or database contents. Back up databases and persistent directories separately, and test restore.
• Persistent apps in a cluster stay on the node that holds their data. Increasing instance count is not a storage story.
• Read the Apache appendix if you fork or redistribute CapRover commercially.

Side by side, without a table

Primary approach

• Coolify: SSH-connected control plane over Docker servers; rich dashboard for apps, databases and one-click services.
• Dokku: git-push PaaS with CLI and plugins; Heroku-like mental model on a server you choose.
• CapRover: web UI on Docker Swarm with captain-definition builds and one-click templates.

Licence (as stated upstream)

• Coolify: Apache 2.0.
• Dokku: MIT.
• CapRover: Apache 2.0 plus project appendix on paid features and redistribution; confirm SPDX and terms yourself.

Latest stable releases checked for this post (November 2026)

• Coolify: v4.6.0 (2 November 2026).
• Dokku: v0.38.34 (30 October 2026).
• CapRover: v1.16.0 (3 November 2026).

Build and deploy feel

• Coolify: Git, Nixpacks/Railpack/Dockerfile/Compose/image; UI-driven.
• Dokku: git push; herokuish buildpacks, Dockerfile, image, or CNB/pack.
• CapRover: captain-definition plus dashboard or CLI upload/build; Dockerfile or image-centric.

Multi-server story

• Coolify: manage many servers from one instance; multi-server app deploy exists with documented limits (Compose and persistent storage excluded from that attach flow; external load balancer still yours).
• Dokku: default docker-local scheduler is single-server oriented; optional other schedulers exist if you choose them deliberately.
• CapRover: Swarm multi-node is a first-class documented path once registry and networking are ready.

SSL and backups

• Coolify: proxy-managed TLS; database backup schedules for several engines with optional S3; instance backup is separate from DB data.
• Dokku: certs plugin and optional Let’s Encrypt plugin; datastore plugins without pretending backups are done for you.
• CapRover: Certbot/Let’s Encrypt for domains; /captain/data config backup; volumes and DB dumps are your job.

We did not run install drills or load tests for this post. Prefer the official install guides on a disposable VPS before you move production traffic.

A practical way to start this week

For an Indian engineering team that still SSHes into one or two VPS hosts, a calm sequence looks like this:

1. List the apps that hurt today: git deploy needs, image-only needs, and databases that need a real dump schedule.
2. Pick one non-production VPS on a fresh OS image. Open only the ports the chosen tool documents.
3. For a dashboard and one-click services, install Coolify with the official script, create the admin user immediately, deploy a trivial image app, then Postgres with backups to S3-compatible storage.
4. For git push and Procfiles, install Dokku with the tagged bootstrap script, set the global domain, deploy a sample app, add Let’s Encrypt only after DNS is correct, and install one datastore plugin you need.
5. For Swarm plus a UI with wildcard DNS ready, install CapRover, secure the dashboard, enable HTTPS, deploy via captain-definition, and practise a config backup plus a separate database dump restore on a second box.
6. Write restore steps in the team wiki: who runs them, where off-server copies live, and how you verify the app after restore.
7. Only then migrate a real internal app. Keep the old Compose path until the new path survives a redeploy and a certificate renewal.

How to choose

• If you want a modern dashboard, multi-server management, Nixpacks/Compose options and built-in database backup UI, start with Coolify.
• If you want the smallest Heroku-like CLI surface and are happy living in SSH and plugins, start with Dokku.
• If you want Swarm scaling with a web UI and can accept CapRover’s DNS and backup boundaries, start with CapRover.
• If you are already deep into Kubernetes operators and GitOps, none of these replace that path; they sit below it for teams that do not need a cluster yet.
• Do not run two PaaS control planes on the same production host “just to compare”. Compare on throwaway VMs.

Revisit checklist

• Are we still hand-editing Compose over SSH for every release, or do we have one documented deploy path?
• Do we know who owns OS updates, firewall rules and DNS for the PaaS host?
• Is TLS automated, and do we know what happens when HTTP-01 or DNS validation fails?
• Are database dumps separate from platform config backups, stored off the server, and restored at least once?
• For multi-server dreams: do we have shared state, a registry and a load balancer plan, or only hope?
• Can a new teammate ship a staging app without receiving the root password in chat?
• Have we pinned the PaaS version and read the release notes before the next upgrade?

Treating a VPS as a home-made Heroku is fine for a learning weekend. Shipping production that way is a habit worth unlearning. Revisit Coolify, Dokku or CapRover with the same mindset you use for any other platform choice: learn the model, unlearn the one-off SSH ritual, re-learn the backup boundaries, practise on a disposable server, and apply the chosen tool only where it reduces real toil.