Coolify vs Dokploy vs Kamal: Choose Your Self-Hosted PaaS

Choose the workflow you want to maintain

You are choosing how deployments happen on your VPS and how you recover when they fail. We recommend Coolify as the starting point for a small team that wants a deployment dashboard, Dokploy for an existing Compose workflow, and Kamal for operators who prefer reviewed configuration and command-line releases.

Our default here is a single VPS running Ubuntu 24.04 LTS. A self-hosted PaaS gives you application deployment conveniences, but you still own the operating system and the recovery plan. If you have not settled on that responsibility, start with the VPS deployment ladder before installing a panel.

These are workflow recommendations, not claims that a feature belongs exclusively to one product. Coolify supports Compose, and Dokploy can deploy applications without an existing Compose file. Choose by the work your team can understand during an incident, rather than the longest feature list.

Pick Coolify when the dashboard is your operating interface

Coolify suits a developer who wants deployment settings and application operations in a shared interface. It accepts Git-based applications, Dockerfiles and existing container images, including a Compose definition from a repository. Its application documentation also covers domains, health checks and deployment history. See the Coolify application documentation for the supported paths.

We would start here when different teammates need to inspect deployments without learning a collection of custom scripts. A dashboard can make the configured state easier to find, especially when the person investigating did not build the application. That benefit depends on keeping configuration changes deliberate and documenting settings that live outside Git.

Keep your Dockerfile and non-secret deployment definitions in the repository even when the panel can generate them. Record where production variables are stored and how an operator retrieves them during recovery. Treat the dashboard as another application you maintain, with its own access controls and recoverable configuration.

Pick Dokploy when Compose already describes your application

Dokploy is a sensible candidate when your repository already describes the application as a Compose project. Its documentation distinguishes ordinary Docker Compose deployment from Docker Stack deployment through Swarm. Stack mode has different behavior and does not support every Compose feature, including building images through build. Check the Dokploy Compose documentation before choosing the mode.

For a single VPS, start with ordinary Compose unless you can name a requirement that calls for Swarm. A familiar file format does not guarantee identical execution behavior across modes. In particular, do not select a cluster-oriented option and assume your local development setup will behave unchanged.

Pay attention to environment variables during the first deployment. Dokploy writes UI-defined Compose variables into a .env file, but your Compose definition must still reference or load them into the relevant containers. Explicitly mapping the variables each service needs makes accidental secret exposure easier to spot.

We would keep the repository authoritative and review changes to persistent mounts before every migration. Dokploy's documented volume-backup feature covers named volumes rather than bind mounts, so your storage choice affects recovery options. Work through the production Compose checklist before treating a successful deployment as production readiness.

Pick Kamal when deployment belongs in reviewed automation

Kamal fits operators who want deployment configuration beside application code and releases initiated from a workstation or CI. It is a command-line deployment tool, so do not choose it expecting a shared web dashboard. We would favor this model when every production change should arrive as a reviewable repository change.

Kamal's deployment flow builds and publishes an image, pulls it onto the target server, and starts the replacement application container. Its proxy moves traffic after the replacement passes its health check, then the old container is stopped. The Kamal deployment documentation explains that sequence.

That handover still needs application support. Configure readiness to reflect whether the app can serve requests, and allow enough capacity for overlapping containers. Database migrations must remain compatible with the old application while both releases can be active.

Kamal can manage supporting containers as accessories, but they have a separate lifecycle. They are not updated with an ordinary application deployment, and their updates do not receive the same uninterrupted handover. Read the Kamal accessory documentation before putting a database under that workflow.

Keep a documented way to deploy from a replacement workstation or runner. Production should not depend on an unrecorded local setting on one developer's laptop. Store credentials outside Git and make their recovery part of the deployment procedure.

Size the VPS for deployments as well as steady traffic

A server that comfortably serves requests can still struggle while compiling an application image. Builds compete with production for memory and CPU, while cached layers consume disk. If builds disturb the running application, move image building to CI or a separate builder and deploy the resulting image.

Leave room for the previous application image and temporary overlap during releases. Watch disk growth from logs and image layers, and define cleanup rules that preserve your recovery target. Avoid choosing a VPS solely because an empty installation starts successfully.

When comparing hosts, use the hosting options for Coolify to evaluate capacity and recovery access for the same workload. An independent console is useful when a firewall mistake breaks SSH. Provider snapshots can help with some recovery tasks, but application data still needs a backup plan you can restore.

A single VPS remains a shared failure boundary regardless of the deployment interface. Replacing a container without interrupting requests does not keep the application online when its host disappears. Only add servers when the availability requirement justifies the extra operational work.

Separate release rollback from data recovery

An application rollback starts older code; it does not automatically restore the database that code expects. A migration that removes a field can make the previous image unusable even when that image remains available. Prefer additive schema changes, then remove obsolete structures after the rollback window closes.

Keep a known-good image available by an immutable reference. Rebuilding an old commit is a weaker recovery plan because its external dependencies may have changed or disappeared. Decide how long you need that recovery target before enabling automated image cleanup.

• Application database: use an engine-aware backup method and restore it into an isolated destination.
• Uploaded files and persistent volumes: identify the actual storage location and choose a consistency-safe backup method.
• Deployment configuration: preserve the definitions and settings required to recreate the application.
• Recovery credentials: retain access to secrets and any encryption keys needed to use the backups.

Keep backup copies outside the production VPS and verify that you can retrieve them without its dashboard. A panel backup should never be assumed to contain every workload's data. Use the VPS backup and restore procedure to turn that inventory into a recoverable system.

A meaningful restore check opens the recovered application and reads known records or uploaded files. A successful backup job only confirms that its configured work completed. Write down the restore destination and the expected application behavior before you need either.

Give Claude Code a bounded deployment role

We recommend Claude Code for inspecting deployment definitions and preparing changes you can review. Start with repository access and sanitized logs, then add narrowly defined production operations only when they are needed. A useful request names the affected application and the evidence the agent must collect before proposing a fix.

Ask Claude Code to explain a failing health check or prepare a configuration diff before granting permission to deploy it. Keep data deletion and credential changes behind explicit approval. Follow the production agent guardrails when defining those boundaries.

A deployment dashboard does not automatically make an agent's access narrow. Check the actual token permissions, and treat access to the Docker socket as administrative control of the host. With Kamal, protect the workstation or CI runner that holds deployment credentials just as carefully.

Use one authoritative deployment path for each application. If the panel manages a service, avoid having an agent independently replace its containers through SSH. Emergency manual changes should be recorded and reconciled with the deployment configuration before the next release.

Run a disposable deployment before moving production

Start with the option that matches your current workflow and give it a disposable application on Ubuntu 24.04 LTS. Use representative persistence if your real application stores data, but keep production credentials out of the trial. Follow the project's installation instructions on a clean VPS so existing proxy services do not obscure the result.

Deploy a baseline. Configure a real hostname and the application's readiness endpoint, then deploy a release with a visible identifying marker. If the application stores files, create a disposable upload through its normal interface.

Exercise release recovery. Deploy a harmless change to the marker, then use your chosen workflow to return to the retained baseline image. Observe request failures during both operations instead of assuming the handover is uninterrupted.

Restore into an isolated destination. Back up the disposable application's data and recover it without overwriting the original. Record every setting or credential that the restore required but the backup did not contain.

Before moving production, commit the deployment definition and write the recovery instructions using what the trial exposed. Keep unresolved failures as explicit blockers. Your next production action should be a scheduled migration with a retained recovery target and a named operator watching application behavior.