Coolify vs Dokku: which to choose

Coolify vs Dokku: when each platform fits your team

Coolify fits teams that want a web dashboard and several servers under one control plane. Dokku fits a single host driven by `git push`. If you need a self-hosted Heroku-style platform for more than one machine, or for people who prefer clicking through a UI over a terminal, start with Coolify. If you have one server, a small team of developers comfortable with Git remotes and the command line, and little need for a graphical interface, Dokku keeps the moving parts low. Four decision points settle most cases: how many servers you will run, who deploys (developers pushing code, or an operator managing services), what access your team needs (shared dashboard roles versus SSH and Git keys), and how much operating work you want to own.

Both platforms are free to self-host. Coolify is licensed under Apache-2.0 and Dokku under MIT, so the license does not separate them on cost. The difference is operational: Coolify connects to each server over SSH and manages it, while Dokku runs on the host itself and leaves scaling across machines to a separate scheduler. Ask which of those operating models your team can staff, patch and back up over the next few years. Check current version support in each project's release notes before you commit, since Coolify v4.4.6 and Dokku v0.38.31 are the latest releases named in the supplied facts and both projects change quickly.

Which platform fits which scenario

This table maps common team situations to the platform that fits better and the condition under which the other one would win. Read each row against your server count, who deploys, and whether you need a dashboard, git push, or identity controls. Confirm SSO and team permission details directly with each project before you decide.

Scenario	Better fit	Why, and when the other platform wins
Solo developer with one VPS	Dokku	Runs on a single server with git push and buildpacks, and needs 1 GB of RAM for the default Docker scheduler. Coolify wins if you want a web dashboard to manage databases and backups on that same server.
Small team wanting a dashboard for non-CLI users	Coolify	Coolify provides a web dashboard for apps, databases, backups and deployments, so people who avoid the terminal can operate it. Dokku wins if everyone is comfortable with git and the CLI and you want fewer moving parts.
Platform team running several servers	Coolify	Coolify connects to each server over SSH and deploys across them from one instance. Dokku's default scheduler runs on the single Dokku host, and its K3s scheduler needs a Docker registry and only the initial server is the git push target, so Dokku wins only if you accept that model or plan a Kubernetes-style cluster.
Team that wants Heroku-style git push workflows	Dokku	Deploys with git push to a dokku remote, creates apps on the fly, and supports Procfiles, the release process type and ps:scale. Coolify wins if your team prefers connecting a Git repository through a UI rather than pushing to a remote.
Team that needs preview deployments from pull requests	Coolify	Coolify builds pull or merge requests from GitHub, GitLab, Gitea and Bitbucket and deletes them when closed, but it needs wildcard DNS for the default URL. Dokku does not document an equivalent preview feature in the supplied facts, so confirm with the project if previews are required.
Team needing strict SSO, SCIM or audit logs	Neither by default, confirm first	The supplied facts do not establish SSO, SCIM or audit logging for either platform. Ask each project directly how team roles, identity federation and activity records work in the version you plan to run, and treat a missing answer as a gap to close before choosing.
Team that needs managed databases with scheduled backups	Coolify	Coolify's scheduled backups cover PostgreSQL, MySQL, MariaDB, MongoDB and ClickHouse, with S3-compatible upload. Dokku's dokku-postgres plugin also runs scheduled backups to S3-compatible storage, but covers Postgres only in the supplied facts, so Dokku wins if you need only PostgreSQL and prefer plugin-based control.
Team standardizing on an MIT or Apache-2.0 open-source license	Dokku or Coolify, depending on need	Dokku is MIT licensed and Coolify is Apache-2.0, so both fit permissive licensing needs. Choose on operating model rather than license, and confirm any future licensing or edition changes in each project's repository.

How Coolify manages servers over SSH and Dokku runs on one host

Coolify and Dokku make different bets about where workloads run and where control lives. The cards below walk through the architectural choices that decide where failures land, what must be backed up and how many machines your team will operate.

Coolify reaches each server over SSH

Coolify connects to every server you add over SSH, prepares it to run Docker workloads and deploys applications from a Git repository, Dockerfile, Docker Compose file or prebuilt image. Day to day, the control plane must keep reaching each host, so SSH access, key rotation and network paths between the Coolify instance and every server become operational dependencies. Confirm how your team will manage those keys and what happens to deployments when a server becomes unreachable.

One coolify-proxy per server

Coolify runs a coolify-proxy container on each server, with Traefik as the default and Caddy as the alternative, and both handle HTTPS automatically. The Custom (None) option hands routing and TLS certificates back to your team. Each server therefore has its own routing layer to patch, monitor and troubleshoot, and a proxy fault on one host affects only the apps on that host. Decide early which proxy you will standardize on and who owns certificate handling.

Single install script with Linux prerequisites

Coolify installs with a single script and needs at least 2 CPU cores, 2 GB RAM and 10 GB of free disk on a supported Linux distribution, on amd64 or arm64. The Coolify instance itself is a stateful service with its own configuration, so the host running it needs the same backup discipline as any control plane. Confirm your distribution is on the supported list and plan for restoring the instance, not only the apps it deploys.

Dokku's single-server design

Dokku runs on a single server, and its default docker-local scheduler runs containers directly on that host. A host failure takes down every app Dokku runs, so availability depends on that one machine and on how quickly you can rebuild it. Dokku needs 1 GB of RAM for the default Docker scheduler and supports Ubuntu 22.04, 24.04 and 26.04 and Debian 11 or later. Plan the host rebuild and the restore of app data as one procedure.

Optional k3s scheduler needs a registry

Dokku's k3s scheduler, introduced in Dokku 0.33.0, builds a multi-server K3s cluster, but it requires a Docker registry to hold the images it deploys. That adds a component you must run, back up and secure, and the cluster brings Kubernetes-level operations into a platform chosen for simplicity. Ask whether your team already operates a registry and Kubernetes skills before choosing this path.

Only the initial server takes git push

With the k3s scheduler, only the initial Dokku server is configured as the git push target, even though workloads may run on other nodes. Deploy access, deploy logs and the place where Git pushes land all concentrate on that first host, which becomes a single point of control even in a multi-server layout. Document how that host is backed up and how your team would redeploy if it were lost.

Capability differences that affect daily work

This table compares the day-to-day capabilities of Coolify and Dokku, from licensing and deployment model to backups, previews and scheduling. Read each row against your own servers and team workflow, and treat cells marked for confirmation as questions to put to each project's current documentation. The main takeaway is that Coolify manages many servers and a web dashboard, while Dokku stays a git-push tool on one host unless you adopt its k3s scheduler.

Capability	Coolify	Dokku
License	Apache-2.0 (coollabsio/coolify repository)	MIT (LICENSE file in dokku/dokku, 2014 copyright by Jeff Lindsay)
Current version and release status	v4.4.6, released October 9, 2026; v5 previewed in notes while v4 stays supported	v0.38.31, released September 27, 2026; still versioned 0.x
Deployment model	Web dashboard that connects to servers over SSH and prepares them for Docker workloads	Command-line PaaS with git push to a dokku remote, running on a single server
Server count supported	Multiple servers managed from one instance	Single server by default; k3s scheduler adds a multi-server cluster
Build methods	Git repository, Dockerfile, Docker Compose, prebuilt image; Nixpacks, Railpack (beta), Static, Dockerfile, Docker Compose	herokuish buildpacks, Cloud Native Buildpacks (pack CLI), Dockerfile, Nixpacks (from 0.32.0), Railpack (from 0.37.0), Lambda or null
Docker Compose support	Yes, Docker Compose file is a supported deployment source	Dockerfile-based deployment; confirm current Compose handling in Dokku docs
Database engines offered	PostgreSQL, MySQL, MariaDB, MongoDB, Redis, Dragonfly, KeyDB, ClickHouse	No datastores by default; official plugins add Postgres, MySQL, MariaDB, Redis, Mongo, ClickHouse, Elasticsearch and others
Scheduled database backups and engines covered	PostgreSQL, MySQL, MariaDB, MongoDB, ClickHouse; not Redis, Dragonfly or KeyDB	Scheduled backups through the official dokku-postgres plugin; confirm coverage for other plugins
S3-compatible backup upload	Supported for PostgreSQL backups	Supported by dokku-postgres plugin backups
Restore and import formats	PostgreSQL SQL dumps, custom archives, tar archives and all-database dumps	postgres:import for database imports; confirm formats per plugin
Preview deployments	Built from GitHub, GitLab, Gitea and Bitbucket pull or merge requests; needs wildcard DNS	Not documented as a built-in feature; confirm with current docs
Proxy options	Traefik (default), Caddy, or Custom (None) with operator-managed routing and TLS	Proxy management documented in Dokku docs; confirm available proxy choices
Process scaling	Managed through the dashboard per application and server	Procfile process types scaled with ps:scale; web scales to 1 on first deploy
app.json and Procfile support	Not a documented input for deployments; confirm with Coolify docs	Procfile read under strict mode; app.json supported with noted gaps versus Heroku
k3s scheduler	Not applicable; multi-server handled by SSH-managed servers	Available since Dokku 0.33.0; needs a Docker registry and only the initial server is the git push target

What is free, what is paid and what is still open

Coolify is licensed under Apache-2.0, and its pricing page describes the self-hosted edition as free forever with all features and no limitations or restrictions. You run the dashboard on your own server, so the software itself carries no license fee. The paid option is Coolify Cloud, where Coolify runs the control plane on its managed infrastructure while your applications still run on servers you bring.

Self-hosted license: Apache-2.0 under the coollabsio/coolify repository, with the pricing page stating the self-hosted edition includes all features.
Cloud fee: $5 per month for 2 connected servers plus $3 per month for each additional server, according to the pricing page.
Annual discount: 20% for annual billing on Coolify Cloud, per the same page.
What the cloud fee does not cover: You still provide and pay for the servers your apps run on.
Recurring costs: Your servers, storage, backup targets and DNS, which you pay to your own providers whichever edition you choose.

Before you commit, confirm with Coolify which features, if any, depend on the cloud plan and what the control plane availability terms are. Also check your own hosting bill for every server you plan to connect.

What drives the running cost of each platform

Neither Coolify nor Dokku charges a license fee for self-hosted use, so the running cost comes from the servers, the people who maintain them, the backup storage and the work you buy or do yourself. The cards below separate one-time work from recurring spend and list what to ask for in any quote.

Server infrastructure

Coolify needs at least 2 CPU cores, 2 GB RAM and 10 GB of free disk on the instance that runs it, and each additional server you manage over SSH carries its own hosting cost. Dokku needs at least 1 GB of RAM for the default scheduler, but it runs on a single host, so its server line is usually one machine. Multi-server Coolify therefore scales its recurring hosting cost with server count, while Dokku's k3s scheduler adds a registry and cluster to maintain. Confirm the server count and sizing you need before comparing totals.

Staff time for upgrades

Upgrades and host maintenance recur for both platforms, and they are the largest ongoing cost for most teams. Coolify is an actively released Apache-2.0 product with a v4 line and a planned v5, so your team should budget for dashboard and proxy upgrades. Dokku is versioned 0.x, so breaking changes between minor releases are possible and need testing on a staging host first. Ask the vendor or partner who owns patching the host OS, the platform and its plugins.

Backup storage and restore testing

Backup storage is a recurring line that you pay directly to an S3-compatible provider. Coolify's scheduled backups cover PostgreSQL, MySQL, MariaDB, MongoDB and ClickHouse, but not Redis, Dragonfly or KeyDB, so any data in those engines needs a separate plan and cost. Dokku's dokku-postgres plugin can also back up to S3-compatible storage. Retention settings drive storage growth, and restore tests consume time that a backup schedule alone does not show. Ask for restore test results, not only backup job logs.

Implementation services

Implementation is usually a one-time cost, but its size depends on whether you buy help. A fixed-scope engagement sets scope, deliverables and timelines in writing before work starts, so you can compare the quote against your own staff hours. Typical scope items include host hardening, database engine choices, backup design and a migration plan from existing hosting. DeployOpen does not publish a price list, so request a written quote that lists each component separately.

Switching and re-platforming later

Switching is a one-time cost that grows with how much you customize the platform. Coolify's Docker Compose and Dockerfile deployments can move to other Docker hosts, while Dokku's buildpack and git-push workflow depends on Dokku's own app layout and plugins. Plan for the cost of migrating databases, DNS, certificates and preview wildcard domains if you leave either platform. Ask any implementation partner to estimate the exit path as part of the first scope, before you commit.

Where Coolify and Dokku rollouts usually run long

Coolify's effort starts before the dashboard is useful. Each server must be prepared over SSH so it can run Docker workloads, and the host needs at least 2 CPU cores, 2 GB RAM and 10 GB of free disk, so confirm those on every node before you plan the install. Choosing the proxy is a real decision: Traefik is the default and Caddy is the alternative, both handle HTTPS automatically, but the Custom (None) option hands routing and certificates back to your team. Preview deployments add DNS work, because the default {{pr_id}}.{{domain}} URL needs a wildcard record that someone must own and renew. The most common delay is database backups. Scheduled backups cover PostgreSQL, MySQL, MariaDB, MongoDB and ClickHouse, but not Redis, Dragonfly or KeyDB, so any cache or key store in your design needs its own recovery plan. Schedule a restore test for each covered database early in the project, using the Import Backup path, before production data depends on it.

Dokku's effort is front-loaded on the host and the toolchain. Dokku runs on a single server, so capacity planning, failover and host patching all sit on one machine unless you move to the k3s scheduler, which requires a Docker registry and only configures the initial Dokku server as the git push target. If you use Cloud Native Buildpacks, the pack CLI must be installed separately, and someone must pin and maintain it alongside the builder stack. Datastores are not included: each one arrives through an official plugin such as dokku-postgres, so plan plugin installation, version checks and backup configuration for every service your apps need. Confirm which PostgreSQL version your chosen plugin installs, since it is set by the plugin rather than by the platform.

Moving from Dokku to Coolify, or back, without losing data

This sequence moves each app and its data to the other platform while the old host keeps serving traffic, so you can verify restores and DNS before anything is shut down. The result is a tested rollback path and a documented inventory of what was carried over and what was rebuilt.

Inventory apps, variables and domains
On the source host, list every app, its process types from the Procfile, its environment variables, its attached datastores, its custom domains and any scheduled tasks or app.json hooks. Record the Git remote, Dockerfile, Compose file or image each app is built from. Store this inventory somewhere the team can review it. You know this step is done when every app has one row covering source, variables, domains, datastores and schedules, and someone other than the author has checked it against the live host.
Rebuild each app as a Coolify resource
Create each application in Coolify from the same Git repository, Dockerfile, Docker Compose file or Docker image recorded in the inventory. Choose the build pack deliberately: Dokku's Cloud Native Buildpacks, Nixpacks or Railpack builds do not carry over automatically, so confirm the build method for each app and set the port, environment variables and health behavior manually. Source code and the Git history transfer; build settings, proxy routes and process scaling are recreated in the Coolify dashboard. You know this step is done when a test deployment of each app starts and passes a smoke request on a non-production hostname.
Export and restore databases with verified dumps
Export each datastore from the source host. On Dokku with the dokku-postgres plugin, use postgres:export; Coolify's Import Backup accepts PostgreSQL SQL dumps, custom archives, tar archives and all-database dumps. Restore the file into a new Coolify database, then point a test copy of the app at it and run your application's read and write checks. Confirm which datastores Coolify backs up on schedule (PostgreSQL, MySQL, MariaDB, MongoDB and ClickHouse) and rebuild backups for the rest, such as Redis, separately. You know this step is done when row counts and a sample of application queries match the source, and a restore from a fresh Coolify backup has been tested.
Reconfigure DNS and TLS for the new host
Lower the TTL on the production records ahead of the cutover, then add the custom domains to the Coolify resources. Coolify's proxy (Traefik by default, Caddy as the alternative) issues HTTPS certificates automatically when DNS resolves to the server. If you use the Custom (None) proxy option instead, you provision and renew certificates yourself. Rebuild preview deployments here too, since they need wildcard DNS and a Git provider connection. You know this step is done when each domain resolves to the new server, serves a valid certificate, and the old host still answers on its own addresses for rollback.
Run both platforms in parallel
Keep the Dokku host live while the Coolify copies run against the same data flow. Send a limited share of traffic or a staging hostname to Coolify, watch error rates and logs on both sides, and confirm that scheduled jobs run once, not twice. Writes made during this window must go to one database only, so decide the primary before cutover. You know this step is done when a defined soak period with your own success criteria has passed without an unresolved defect, and the team has signed off in writing.
Cut over and decommission the old host
Freeze writes on the source, take a final export, restore it into the Coolify database, switch DNS fully and verify production traffic. Keep the Dokku host powered but unrouted for a retention period your organization sets, and keep its last backups. Only after that period, remove the Dokku apps, plugins and server access, revoke SSH keys and deploy keys, and archive the inventory. You know this step is done when the old host has no active routes, its final backups are stored and tested, and access revocations are recorded.

Questions buyers ask before choosing or hiring help

Can a solo developer run Coolify or Dokku without outside help?

Yes, for a single server and a small app set, both are workable for a developer comfortable with Linux, SSH and Docker. Coolify installs with a single script and manages its servers through a web dashboard, while Dokku is driven from the command line over git push. The effort rises with the number of servers, databases, domains and backup obligations you take on. Read the Coolify installation docs and the Dokku installation docs and test a restore before you rely on either for production data.

How much time do setup and upgrades take, and what drives it?

The time depends on your server count, your databases, your domain and DNS setup, your build methods and how much you automate around them. Neither vendor's documentation gives a fixed duration for your environment, so ask for an estimate against a written scope rather than relying on a generic figure. Upgrade effort grows with the number of apps, custom proxy rules and third-party plugins you run. Coolify v4.0.0 was the first stable release, and Dokku is still versioned 0.x, so check each project's release notes before planning an upgrade window.

What skills does the team need to run either platform?

Plan for Linux administration, Docker knowledge, DNS management and a tested backup routine. Coolify expects SSH access to each server it manages and a working wildcard DNS record if you use preview deployments, which Coolify documents as a default URL pattern. Dokku needs a host where you can manage the git remote, Docker and plugin updates yourself. Backup testing matters most: take a restore drill for each database type you run, because a backup that has never been restored is not evidence that recovery works.

Can Coolify manage more than one server, and what does Dokku need for multi-server use?

Coolify connects to multiple servers over SSH and deploys to each one, as described in its multi-server deployments docs. Dokku runs on a single server by default. Multi-server use on Dokku means choosing the k3s scheduler, which requires a Docker registry, and you should confirm how git push targets and application placement behave in your setup before committing. Ask each vendor, or your implementation partner, to demonstrate the exact server count and failover behavior you need.

Does Dokku's k3s scheduler remove the single-host limit?

It removes the single-host limit for workloads only in part. The Dokku K3s scheduler docs describe a multi-server K3s cluster, but only the initial Dokku server is configured as the git push target, and the scheduler requires a Docker registry. Your team takes on the cluster operations, registry management and any routing or storage design that Kubernetes brings. Treat it as a different operating model, and test it against your own workloads before you assume it covers high availability.

Which databases and backups does each platform cover?

Coolify deploys PostgreSQL, MySQL, MariaDB, MongoDB, Redis, Dragonfly, KeyDB and ClickHouse, and its scheduled backups cover PostgreSQL, MySQL, MariaDB, MongoDB and ClickHouse, but not Redis, Dragonfly or KeyDB. Dokku provides no datastores by default, and official plugins such as dokku-postgres add PostgreSQL, MySQL and other services, with backups to S3-compatible storage in the Postgres plugin. Confirm backup scope for each service in the Coolify database backups docs and the plugin README, then plan separate backup handling for anything outside those lists.

How does licensing affect commercial use of Coolify and Dokku?

Coolify is Apache-2.0 licensed, and its pricing page describes the self-hosted edition as free with all features and no limitations or restrictions. Dokku is MIT licensed, and its LICENSE file carries a 2014 copyright by Jeff Lindsay. Both permissive licenses allow commercial use, but your legal team should confirm the terms for any modifications, redistribution or bundled services, and check whether any hosted offering you plan to buy changes the cost picture. Cost comes from the servers, staff time and any partner work you pay for, not from a license fee.

What should a written scope include before hiring a partner?

A written scope should name the platforms and versions, the server inventory and network layout, the applications and build methods, the databases and their backup targets, the DNS and TLS approach, the team's access model, and the handover and documentation expected. It should also state what is out of scope, how upgrades and restore tests are handled, and what happens after go-live. DeployOpen plans, implements, integrates, hardens, backs up, documents and supports self-hosted open-source platforms, and most engagements are fixed-scope with scope, deliverables and timelines agreed in writing before work starts.

How DeployOpen helps you choose, implement or migrate

DeployOpen works on Coolify vs Dokku as a fixed-scope engagement: we start from your servers, team and deployment workloads, then plan, implement, document and hand over the platform inside your own infrastructure. Scope, deliverables and timelines are agreed in writing before work begins.

How we scope

Inventory your servers, workloads, databases and preview needs before recommending Coolify or Dokku for your team.
Agree in writing which platform, server layout, build methods and backup targets the engagement covers.
Confirm with your team which features, such as multi-server support or team access, you need, and which you can defer.

How we build

Install and configure the chosen platform on your own cloud accounts, data centers or air-gapped networks.
Set up database backups, retention and S3-compatible storage targets, and test restores before go-live.
Configure routing, TLS, wildcard DNS for previews and the Git integrations your repositories use.

How we hand over

Document the deployed architecture, server access model, backup procedures and recovery steps for your operators.
Walk your developers and platform engineers through deploying apps, databases and scaling process types.
Deliver written runbooks and configuration records so your team can operate the platform without DeployOpen.

How we support

Offer ongoing support, upgrades and continuous testing as a retainer after the handover is complete.
Plan upgrade windows for Coolify or Dokku releases and test them against your configuration first.
Keep your team in control of the platform, with support scoped and priced separately from the initial build.

Coolify vs Dokku