Migrating from Coolify to DeployHQ

Coolify is one of the strongest open-source PaaS projects in active development — a polished web UI, multi-server management, Heroku-compatible buildpacks, Dockerfile and Docker Compose support, integrated databases (Postgres, MySQL, Redis, MongoDB), automatic SSL via Traefik + Let's Encrypt, and preview deployments per branch. For a team shipping containerized apps and services, it covers an enormous amount of ground.

This guide is not about fixing a problem with Coolify. If your team is happy on Coolify, the honest answer is to stay there.

It is for the specific situations where DeployHQ tends to be the better fit:

1. Self-hosting your deploy tool has become a liability. Coolify runs on a VPS you maintain. When the Coolify host has a problem, you cannot deploy — including the urgent fix that would address the problem. Teams that have been bitten by this once tend to want their deploy tool to live somewhere else.
2. Your stack is not all containers. Coolify is excellent inside its model — buildpacks, Dockerfiles, Compose. It is not the right tool for FTP-only legacy hosts, S3 syncs, Heroku targets, Elastic Beanstalk apps, Kubernetes clusters via kubectl, or atomic file-based releases of framework-shaped apps. DeployHQ deploys all of those plus standard SSH-and-symlink targets.
3. You need governance Coolify does not yet provide. Audit log of every deploy with who-when-what attribution, role-based deploy permissions across environments, deploy approval gates. Coolify is improving here but is not where mature deploy platforms are yet.
4. You want preview-deploy-style branch builds without managing the host running them. Coolify's preview deployments are excellent — but they run on your Coolify server and consume its resources. DeployHQ deploys per-branch to dedicated preview servers without you operating the deploy infrastructure.

For a side-by-side feature comparison, see DeployHQ vs Coolify. If you are weighing other self-hosted PaaS options, DeployHQ vs Dokku and DeployHQ vs Kamal cover similar territory.

This is a model shift, not a one-to-one swap

Coolify is a PaaS. DeployHQ is a deploy automation tool. They overlap on "ship code to a server" and almost nowhere else. Be clear-eyed about what changes:

What Coolify gives you	What DeployHQ replaces it with
Container-based deploys via buildpacks, Dockerfiles, or Docker Compose	Different model. Atomic file-based releases via symlinked release directories — the Capistrano-style approach. Or: container deploys via Custom Actions running docker / kubectl / gcloud / aws.
Polished web UI with project + environment + resource hierarchy	DeployHQ has a web UI too — different shape, deploy-automation-flavoured rather than PaaS-flavoured. Project / environment / server hierarchy.
Multi-server management of a fleet of Coolify-managed hosts	Multi-server deploys per environment, atomic symlink swap in parallel across all targets. No fleet-of-hosts concept — DeployHQ deploys to your servers, it does not manage them.
Built-in Traefik routing and automatic Let's Encrypt	You manage this. Caddy (recommended for new setups — automatic Let's Encrypt out of the box), Traefik standalone, nginx + certbot, or terminate at the load balancer.
Integrated database resources: Postgres, MySQL, Redis, MongoDB	External services. Managed services (RDS, Neon, Supabase, Upstash, Redis Cloud), or run them as ordinary services on a dedicated server with their own backups.
Application templates / one-click app store (WordPress, Ghost, etc.)	Not replicated. DeployHQ does not have a templated-apps concept; you set up each project deliberately.
Preview deployments per branch on the Coolify host	Per-branch deploys to dedicated preview servers via automatic deployments configured per environment. Different shape, more setup, no shared host pressure.
Per-resource environment variables in the UI	Per-project environment variables plus global env vars shared across projects.
Service discovery via internal Docker networking	You manage this. Direct connection strings, service mesh of choice, or simply put services on the same private network.
Coolify Cloud (managed Coolify)	DeployHQ is managed by default. No self-hosted option.

If half of that table represents work you do not want to take on — Traefik replacement, managed databases, your own preview-deploy harness — Coolify is doing more for you than the migration accounts for, and "stay on Coolify" is a perfectly defensible answer.

Three migration paths

Path 1: Full migration to file-based atomic releases

You give up containers, buildpacks, and Coolify's PaaS abstractions; you gain atomic symlinked releases, multi-server parallel deploys, build pipelines that run off the target, and the governance layer (audit log, RBAC, approvals).

This works well if your apps are framework-shaped (Rails, Laravel, Django, Express) and Coolify's buildpack was largely doing dependency installs and asset compilation. Both translate cleanly into DeployHQ build pipeline steps.

You take on direct responsibility for the things Coolify abstracted: routing/SSL via Caddy, databases as managed services or dedicated hosts, process management via systemd.

Path 2: Keep containers, deploy via Custom Actions

If your apps must stay containerized — Compose-defined services, multi-stage Dockerfiles, Kubernetes targets — Custom Actions (currently in beta) run any CLI tool inside Docker as a deploy step. docker push, kubectl set image, gcloud run deploy, aws ecs update-service, terraform apply all work, with the same DeployHQ audit log, role-based permissions, and rollback story as SSH deploys.

This is the right path if you want the DeployHQ governance layer without de-containerizing your application architecture.

Path 3: Hybrid — keep Coolify for what it does well, use DeployHQ for the rest

If your Coolify setup is genuinely working and the only reason you are reading this is to deploy the other parts of your stack (the legacy FTP host, the S3 marketing assets, the Heroku side project, the Elastic Beanstalk app, the kubectl-managed cluster), the answer might be "both."

DeployHQ does not need to replace Coolify to be useful. Many teams run them side by side for years — Coolify for the containerized core, DeployHQ for everything that does not fit Coolify's model.

Filling the gaps Coolify used to fill

If you choose Path 1 (full migration), here is the practical replacement set:

SSL and routing: Caddy is the closest one-step replacement for Coolify's Traefik + Let's Encrypt. Install once, define a site block per app, automatic HTTPS out of the box. Keep Traefik standalone if you want to preserve the configuration shape.

Postgres, MySQL, Redis, MongoDB: Move to managed services if you can. Coolify makes self-hosted databases easy until the day you need point-in-time recovery, replication, or off-server backups — at which point a managed service is significantly cheaper than your time. If you stay self-hosted, run them on a dedicated server and treat them as ordinary services with proper backups and monitoring.

Application templates: No direct replacement. If you used Coolify's one-click WordPress / Ghost / etc., you set those up directly on a server during the migration. This is a one-time cost.

Preview deployments: Configure a separate DeployHQ environment per branch, or use automatic deployments tied to a wildcard branch pattern. The shape is different — a dedicated preview server rather than ephemeral containers — and the setup is more work, but the resulting previews are more isolated and do not share resources with your other apps.

Service discovery: If your apps relied on Coolify's Docker networking for service-to-service calls, replace with explicit connection strings (env vars), a service mesh, or putting services on the same private network with hostname-based addressing.

Heartbeats and uptime monitoring: Better Stack, UptimeRobot, or your monitoring tool of choice. See sending deploy events to Better Stack for the integration pattern.

Migration in three steps (Path 1)

1. Stand up the new server

Provision a server (or reuse a Coolify host once decommissioned), install your runtime directly, install Caddy for SSL/routing, and configure systemd units for each process type from your Coolify resource.

If you want this off your plate, the Managed VPS beta provisions a server inside DeployHQ in a couple of clicks, with SSH keys handled automatically.

2. Replicate the buildpack as a build pipeline

Most Heroku-style buildpacks resolve to a small set of commands. Translate them into DeployHQ build pipeline steps:

• Ruby/Rails: bundle install --deployment --without development test, bundle exec rails assets:precompile
• Node: npm ci --omit=dev, npm run build
• PHP/Laravel: composer install --no-dev --optimize-autoloader, npm ci && npm run build
• Python/Django: pip install -r requirements.txt, python manage.py collectstatic --noinput
• Static site: Whatever your build command produces in dist/ or public/

These run once on our build infrastructure; the resulting release ships to every target.

3. Wire deploy hooks as SSH commands

Anything Coolify ran on container start, or that you triggered post-deploy, becomes an SSH command tied to a deploy stage:

• Database migrations: bundle exec rails db:migrate, php artisan migrate --force, python manage.py migrate — after upload, before symlink change
• Service restart: sudo systemctl reload puma, sudo systemctl restart php-fpm — after deploy
• Cache warmup, queue restart, etc. — after deploy

For a typical Coolify app, end-to-end migration is a full day — closer to the Dokku migration in scope than the script-based migrations in this series, because you are also taking on routing, SSL, databases, and process management. Migrate one app at a time and run both setups in parallel until you are confident before decommissioning Coolify. Concierge migration is available on Pro and above — point us at your Coolify setup and we will do the migration with you on a screenshare.

What teams ask before they switch

Coolify's UI is genuinely good. What am I trading? Coolify's PaaS-shaped UI for DeployHQ's deploy-automation-shaped UI. Different focus: Coolify centres on resources (apps, services, databases) and their configuration; DeployHQ centres on deploys (audit log, history, rollback, approvals). Most Coolify migrants describe the trade as "I miss the integrated database UI; I do not miss self-hosting the dashboard."

What about my Coolify databases? Dump and restore into your new database (managed service or self-hosted on a dedicated host). Do this once during the cut-over window — the data migration is independent of the deploy migration.

Can I keep using my Coolify servers? Yes — but only after Coolify is fully removed. Coolify customises Docker, Traefik, and process layout heavily. Migrating means tearing that down or spinning up fresh servers. Most teams find fresh servers easier.

What about preview deployments? Honestly, Coolify is currently better at this. DeployHQ supports per-branch deploys but the shape is different — dedicated preview servers rather than ephemeral containers on a shared host. If preview deploys are core to your workflow, factor that into your decision.

Do I have to give up git push deploys? No. DeployHQ supports automatic deployments on every push to a tracked branch via webhooks from GitHub, GitLab, Bitbucket, and self-hosted Git. The developer experience of "push and it deploys" is preserved; the path between the push and the running app is just different.

What if I want to keep containers but move off Coolify? Path 2 (Custom Actions) is your route. Or evaluate dedicated container platforms — see DeployHQ vs Kamal for the trade-offs, and Migrating from Kamal to DeployHQ if you eventually outgrow that too.

Is DeployHQ self-hostable? No — DeployHQ is managed-only. If self-hosting your deploy tool is a hard requirement, staying on Coolify (or evaluating alternatives like Dokku, Kamal, or running your own scripts) is the right call.

Start your migration

Stand up a new server (or use the Managed VPS beta), connect a DeployHQ project to your repo, replicate your Coolify buildpack as a build pipeline, wire your post-deploy hooks as SSH commands, and migrate one app at a time. Plan for a full day per app and a parallel-running period before you decommission Coolify.

If your stack is part Coolify-shaped and part not, consider Path 3 (hybrid) before committing to a full migration. There is no requirement to move everything.

Coolify is a trademark of Coollabs. DeployHQ is not affiliated with the Coolify project. We just understand what the migration looks like when a self-hosted PaaS stops being the right shape for the job.