Coolify vs Dokploy on a single VPS

Coolify vs Dokploy: the short answer

Coolify vs Dokploy is mostly a choice between two architectures. Coolify runs one control instance that manages servers over SSH, including the server it lives on. Dokploy turns your VPS into a Docker Swarm node and puts Traefik in front of every app. On one small VPS both work well. The difference shows up when you add a second server. It shows up again when you need to back up the platform or leave it.

This guide is for a reader who has already decided on a self-hosted deploy platform. If you are still comparing app-store platforms, where you click "install" on a ready-made app, read how Cloudron, CasaOS and Coolify compare as app platforms first. A deploy platform works differently: it takes your own code or your own compose file and runs it. It also handles domains and TLS (transport layer security) certificates for you.

Why the architecture decides everything else

Both tools give you a dashboard and git-based deploys with automatic HTTPS. The dashboards look similar. What sits underneath does not, and that part decides how each tool behaves when something goes wrong.

Coolify: a control instance that drives servers over SSH

Coolify is a web application with its own PostgreSQL database and Redis. It keeps a list of servers, and it reaches each one over SSH (secure shell). It then runs Docker commands on that server. A fresh install has exactly one server in that list. It is named localhost, and it is the same machine Coolify runs on.

This detail matters. Coolify does not talk to the local Docker socket the way a simple dashboard would. The installer creates an SSH key under /data/coolify/ssh/keys/. It adds the public half to the authorized_keys file of the user that ran the install. Coolify then logs in to its own host over SSH, the same way it logs in to a remote one. If you later harden SSH and delete that key, Coolify loses its connection to its own host, because the key it uses is no longer accepted.

The model is simple to reason about. There is one control instance and many servers, and each server is just a Linux box with Docker that accepts an SSH key.

Dokploy: Docker Swarm with Traefik in front

Dokploy is built on Docker Swarm, which is Docker's built-in clustering mode. The installer runs docker swarm init, so even a single VPS becomes a one-node swarm. Dokploy's own parts run as Swarm services: the dokploy web service and its database, dokploy-postgres. Traefik is the reverse proxy that routes each domain to the right app. It runs as a container named dokploy-traefik and reads its config from /etc/dokploy/traefik/.

Swarm brings its own state with it. The installer stores the database password and an auth secret as Docker secrets inside the swarm. It also creates an overlay network called dokploy-network. You can see all of this on the box:

sudo docker service ls
sudo docker secret ls
sudo docker network ls --filter name=dokploy

docker service ls should list dokploy and dokploy-postgres with 1/1 replicas. docker secret ls should list dokploy_postgres_password and dokploy_auth_secret. So the swarm itself is part of the platform's state, and you cannot throw it away like a plain runtime.

Dokploy can also manage other machines. It adds remote servers over SSH and installs only a Traefik instance on them, so the dashboard stays on one box. You can also join more machines to the swarm as nodes. These are two different ways to grow, so know which one you are using.

The licences, stated exactly

Coolify is licensed Apache-2.0. Dokploy is licensed Apache-2.0 outside a /proprietary directory in its repository, and that directory carries its own licence. If licence terms matter to your organisation, read that directory's licence file yourself before you build on it.

Installing each one on a fresh VPS

Use a fresh VPS for each. Do not install both on the same box, because both want ports 80 and 443 for their proxy. Dokploy's installer checks this first. It stops with Error: something is already running on port 80 if another process already uses the port. The same check runs for 443 and for 3000, which is the port of Dokploy's dashboard.

Both installers are shell scripts that you pipe from the vendor's site into a root shell. Read the script first if your policy requires that. Both scripts need root, so start a root shell first.

Coolify, from its official installation page:

sudo -i
curl -fsSL https://cdn.coollabs.io/coolify/install.sh | bash

The dashboard is then on port 8000. The first account you register there becomes the admin. Create it right away, before anyone else finds the port.

Dokploy, from its official installation page:

sudo -i
curl -sSL https://dokploy.com/install.sh | sh

The dashboard is then on port 3000. The script may print ERROR: We couldn't detect your server IP address. This means it could not work out which address Swarm should advertise. Set the address yourself and run the script again, for example curl -sSL https://dokploy.com/install.sh | ADVERTISE_ADDR=203.0.113.10 sh, using your own server's address. Your provider's private network may use the same range as Swarm's default overlay pool. In that case, pass a different --default-addr-pool in DOCKER_SWARM_INIT_ARGS, which the installer reads, so the ranges do not overlap.

Open the ports on the VPS firewall. Also open them on your provider's network firewall, which is often a separate setting in the panel:

sudo ufw allow 22/tcp
sudo ufw allow 80/tcp
sudo ufw allow 443/tcp
sudo ufw allow 8000/tcp

For Dokploy, use 3000/tcp instead of 8000/tcp. When the dashboard has its own domain with HTTPS, close the raw dashboard port again. One warning about ufw: Docker writes its own iptables rules for published ports. A port that Docker publishes can be reachable even when ufw does not list it. Test from another machine with curl -I http://<server-ip>:8000 rather than trusting ufw status.

Your apps will run beside the platform, so the box needs memory and disk for both. To work out how much, use the VPS sizing guide for common workloads. The platform is one more workload on the same machine, and on a single VPS it competes with your apps for the same RAM.

What one small VPS means for each

With either tool on one VPS, the control plane and your apps share a machine. That is fine for a personal project, but it has one clear consequence. If the box dies, you lose the apps and the platform at the same moment. So the platform's backup must be stored off the box. The backup section below covers this.

With Coolify, the dashboard, its database, its proxy and your apps all run as ordinary Docker containers. sudo docker ps shows them by name, and they are ordinary in every way. If you already understand how Docker Compose runs services on a VPS, you understand most of what Coolify does on your box.

With Dokploy, apps you deploy as applications run as Swarm services. So docker ps shows task names with a generated suffix, and docker service ls gives a clearer view. Swarm adds a scheduler and an overlay network even when there is only one node. On one VPS it gives you no failover. It does give you the same model you would use on three nodes, so adding servers later is a smaller change.

What changes with two or three servers

This is where the two designs really split.

With Coolify, the clean layout is to move the control instance to its own small server and add the app servers by SSH. Each app server only needs Docker and an SSH key that the control instance holds. If the control instance goes down, your apps keep running, because they are ordinary containers on their own hosts with Docker restart policies. You lose the dashboard and new deploys until the control instance comes back. Jobs that Coolify schedules, such as database backups, also wait.

Dokploy offers two paths. The first is remote servers over SSH, which work much like Coolify: the dashboard stays where it is, and each remote box gets a Traefik instance and your apps. The second path is to join machines to the swarm. Swarm can then move a service to another node when one fails. This only works if the service does not depend on data stored on the dead node. A local Docker volume does not follow a service to a new node. So a database pinned to one node is still a single point of failure. Swarm also needs a manager node to schedule anything. A swarm with one manager has no failover for that role.

So for two or three servers, answer one question first. Do you want one dashboard that reaches separate boxes, or do you want the boxes to act as one cluster? The first is Coolify's natural shape and one of Dokploy's options. Only Dokploy does the second.

How do you back up the platform's own database?

Your app data needs its own backups. This section is about the platform's own state: the list of projects, domains, environment variables and servers. If you lose that, you rebuild every app's settings by hand.

Backing up Coolify

Coolify's state is its PostgreSQL database plus one key. The key is APP_KEY in /data/coolify/source/.env, and Coolify uses it to encrypt values stored in the database. If you restore the database without the matching key, Coolify cannot read the secrets in it. Save the key somewhere off the box first:

sudo grep '^APP_KEY=' /data/coolify/source/.env

Copy that line into your password manager. Then turn on the instance backup in the dashboard under Settings, then Backup. It runs on a cron schedule and keeps a set number of copies. It can also send them to S3-compatible storage. Without S3, the dumps stay under /data/coolify/backups/coolify/ on the same disk. If the disk fails, those dumps are lost too. Also keep a copy of /data/coolify/ssh/keys/, because your other servers trust those keys.

Backing up Dokploy

To run Dokploy's system backup, open the dashboard and go to Web Server, then Backups. It takes the dokploy-postgres database and the /etc/dokploy directory, zips them together, and uploads the file to an S3 destination that you configure. You can set a cron schedule for it. The backup needs an S3 destination, so set one up before you need it.

You also restore from the dashboard, on a fresh install. Restore clears the current /etc/dokploy and drops the current dokploy-postgres database before it loads the backup. Run it on an empty install, not on a box with work you want to keep. If the new server has a different IP address, update it afterwards under Web Server, then Server.

How do you leave each platform?

Both tools deploy ordinary containers. Your apps keep running the day you uninstall the dashboard. But the dashboard was doing jobs that you now have to do yourself. Before you leave either tool, write down how you will replace each of these:

• Builds. The platform may have built your image from a git repository. If so, you now need your own build step and a registry, or a Dockerfile you build on the server.
• Environment variables and secrets. Copy them out of the dashboard. To check them, run sudo docker inspect <container>, which shows the values a running container received.
• Routing and TLS. Each platform wrote proxy rules for your domains. You need your own reverse proxy config, and the new proxy issues fresh certificates. A Traefik reverse proxy for several Docker Compose apps is the closest replacement for both platforms.
• Volumes. Your data lives in Docker volumes or bind mounts. sudo docker volume ls lists them. Point the new compose file at the same volumes, or copy the data out first.
• Scheduled jobs and database backups that you set up in the dashboard. These stop when the platform stops.
• Git webhooks and deploy keys on your git host. They still point at the old dashboard.

Coolify keeps files for each resource under /data/coolify/applications/ and /data/coolify/services/. Dokploy keeps its files under /etc/dokploy/. Look there first, because reusing a compose file is the fastest way out.

Leaving Dokploy has one extra step. Plain docker compose cannot run an app that runs as a Swarm service until you convert it to a compose service. Leave the swarm only after every app has moved. You may still want a web interface for plain containers after you leave. In that case, Portainer on a VPS manages them without taking over builds or routing.

Dokku: the option without a dashboard

Dokku is the third name in this space. It deploys an app when you git push to the server, in the style of Heroku, and you drive it from the command line. It has no web dashboard. If you are the only person deploying and you prefer the terminal, Dokku runs less on the box and leaves less platform state to back up.

Which one should you pick?

Pick Coolify if you want one control instance to manage several separate servers, each one just Docker plus an SSH key. Pick Dokploy if you expect to grow into a cluster and want Swarm's model from the first day. On one VPS, either is a good choice. Plan how you will back up and leave the platform before you deploy your first app. If an AI coding tool built the app you are shipping, see hosting your AI-generated app on a VPS. It covers the steps you need before you pick either platform.

FAQ

Can I install Coolify and Dokploy on the same VPS?

No. Both run a reverse proxy that needs ports 80 and 443. Dokploy's installer checks these ports first. If Coolify's proxy already uses them, it stops with Error: something is already running on port 80. Use one VPS per platform, or remove one platform completely before you install the other.

Do my apps stop if the Coolify or Dokploy dashboard goes down?

No. Running apps keep running, because both tools deploy ordinary containers on Docker or Swarm. The dashboard stops, and so does every job it runs, including new deploys and scheduled backups. On a single VPS this rarely matters. An outage that takes down the dashboard usually takes the apps down too.

What do I need to save to restore Coolify on a new server?

Save the instance database backup and the APP_KEY line from /data/coolify/source/.env. Coolify encrypts stored values with APP_KEY. Without the matching key, a restored database cannot read your secrets. Also keep the SSH keys under /data/coolify/ssh/keys/, because your other servers trust them. Send the database backup to S3-compatible storage. A dump on the same disk is lost if that disk fails.

Why does Dokploy set up Docker Swarm on a single server?

Dokploy is built on Docker Swarm, so its installer runs docker swarm init on every install, even with one node. Its own database runs as a Swarm service. Its passwords are stored as Swarm secrets, which you can see with sudo docker secret ls. On one VPS this gives you no failover. It does give you the same model you would use when you add more nodes later.