Which self-hosted PaaS fits your team's situation
If your team wants Heroku or Render style deployments on servers it controls and expects several machines, start by evaluating Coolify. If the whole app estate fits on one server and your team deploys by pushing to Git, start with Dokku. Both are open source, but the choice turns on how many servers you run, how your developers want to trigger deploys, and how much of the platform's code your legal team will accept under its license.
Coolify is licensed under Apache-2.0 and its pricing page describes the self-hosted edition as free with all features and no limitations or restrictions, so it suits a multi-server, UI-driven setup where you want the full feature set under a permissive license. Dokku is MIT licensed and runs on a single server, deploying with git push to a dokku remote and building with Heroku-compatible buildpacks, which suits a smaller team that wants a thin, scriptable platform. Dokploy is built on Docker and Traefik, but its enterprise features such as SSO, SCIM and audit logs sit in a /proprietary directory under the Dokploy Source Available License 1.0. Choose Dokploy only if your organization accepts that source-available code and its production-use terms, and confirm those terms with counsel before standardizing on it.
All three platforms share a ceiling. Each one manages deployments through its own control plane, and that control plane becomes a dependency your team must back up, upgrade and secure. When you need multi-cluster scheduling, policy-driven rollouts or GitOps across many teams, plan the move to Kubernetes, where a GitOps controller such as Argo CD or Flux can manage the workloads. Before you commit, test your largest app on the candidate platform and confirm how it handles backups, rollbacks and upgrades in your environment.
Which self-hosted PaaS fits each scenario
This table maps common team situations to the self-hosted PaaS option that fits best, with the condition that makes each choice work. Read each row against your server count, build stack and access requirements, and check the Kubernetes row when scheduling needs go beyond a few hosts.
| Scenario | Best fit | Why and the condition that makes it fit |
|---|---|---|
| A single small app on one VM | Dokku | Runs on a single server with git push deploys and a 1 GB RAM minimum for the default Docker scheduler. Fits when one host is enough and you want the smallest moving part. Add official plugins for databases, which Dokku does not provide by default. |
| Several servers managed from one dashboard | Coolify | Connects to each server over SSH and deploys to it from one interface, with Apache-2.0 self-hosted use described as free with all features. Fits when you want a web UI across hosts. Confirm your server count and whether you need Coolify Cloud's managed control plane, which is priced per server. |
| Git push and Heroku buildpacks | Dokku | Deploys with git push to a dokku remote and builds with herokuish, which follows Heroku's v2a buildpack specification. Fits teams whose apps already run on Heroku buildpacks. Heroku functionality is not fully supported, so test your Procfile and app.json before migrating. |
| SSO, SCIM and audit logs | Dokploy Enterprise, or a Kubernetes stack with Argo CD | Dokploy's SSO with OIDC and SAML, SCIM and audit logs sit in source-available proprietary code that requires a commercial agreement for production use. Confirm terms and pricing with Dokploy before committing. Teams that need these controls as open-source components should consider Kubernetes with Argo CD. |
| Multi-node scheduling across many services | Kubernetes (point to the Kubernetes and GitOps pages) | Dokploy's Swarm clusters recommend vertical scaling first, and Dokku's K3s scheduler requires a Docker registry with only the initial server as the git push target. When many services need scheduling, placement and rolling control across nodes, a Kubernetes platform fits better. Confirm the operating effort with your platform team. |
| Self-hosted databases with scheduled backups | Coolify | Deploys PostgreSQL, MySQL, MariaDB, MongoDB and ClickHouse with scheduled backups, though Redis and other key-value stores are not covered. Fits when you need database backups from the platform. Confirm backup and restore procedures for any engine you plan to run. |
Coolify, Dokploy and Dokku in brief
All three tools let a team deploy applications to servers it controls instead of a managed platform. They differ in license, how many servers they are built to manage, and how much of the enterprise tier sits behind a paid agreement.
Coolify
Coolify is licensed under Apache-2.0 and manages servers over SSH, preparing each one to run Docker workloads. The current version on GitHub is v4.4.6, released on October 9, 2026, and v4.0.0 was the first stable release. It deploys from a Git repository, Dockerfile, Docker Compose file or prebuilt image, using Nixpacks, Railpack (beta), Static, Dockerfile or Docker Compose build packs. Check the proxy choice and wildcard DNS requirements for preview deployments before you commit.
Dokploy core and proprietary code
Dokploy's license is split: Apache License 2.0 covers code outside the /proprietary directories, while the Dokploy Source Available License 1.0 governs code inside them. That proprietary code includes SSO with OIDC and SAML, SCIM, audit logs and custom roles, and production use of it requires a commercial agreement. The current version is v0.30.8, released on September 29, 2026. It is designed for multiple servers through Docker Swarm, so confirm which features your tier includes.
Dokku
Dokku is licensed under the MIT license and is built to run on a single server. Its current version is v0.38.31, released on September 27, 2026, and the project is still versioned 0.x. Teams deploy with git push to a Dokku remote, using the herokuish builder, Cloud Native Buildpacks, a Dockerfile, or a Lambda or null builder. Datastores are not included by default, so plan to add official plugins such as dokku-postgres. Multi-server use depends on the separate k3s scheduler.
Single-server versus multi-server fit
Dokku is the clearest single-server option, with a default Docker scheduler that runs containers directly on the host. Coolify manages several servers over SSH, and Dokploy uses Docker Swarm manager and worker nodes. Dokploy's documentation recommends vertical scaling first because horizontal scaling needs more configuration. Ask each vendor how many servers your target architecture needs before you compare prices.
Build methods and databases
All three accept Git-based deploys, but the build methods differ. Coolify offers Nixpacks, Railpack, Static, Dockerfile and Docker Compose. Dokploy adds Heroku and Paketo Buildpacks. Dokku uses herokuish, Cloud Native Buildpacks and Dockerfiles. Database support also varies: Coolify backs up PostgreSQL, MySQL, MariaDB, MongoDB and ClickHouse on schedules, while Dokploy backs up to S3 destinations. Test your own stack against each builder before you choose.
How the three platforms compare on capabilities
This table sets Coolify, Dokploy and Dokku side by side on license, version, server requirements, build methods, databases, backups, preview deployments, multi-server support, paid options and default proxy. Where a cell says to confirm, the vendor documentation did not settle the point, so test it on a trial install before you commit. Use the table as a checklist, since one missing capability in your shortlist can matter more than a strength in another column.
| Capability | Coolify | Dokploy | Dokku |
|---|---|---|---|
| License and current version | Apache-2.0; v4.4.6 released October 9, 2026 | Apache-2.0 outside /proprietary; proprietary code under Dokploy Source Available License 1.0; v0.30.8 released September 29, 2026 | MIT; v0.38.31 released September 27, 2026; still versioned 0.x |
| Minimum server requirements | 2 CPU cores, 2 GB RAM, 10 GB free disk; Linux only, amd64 or arm64 | 2 GB RAM and 30 GB disk; tested on Ubuntu, Debian, Fedora and CentOS | 1 GB RAM for the default Docker scheduler; Ubuntu 22.04 to 26.04 or Debian 11 or later |
| Build methods | Nixpacks, Railpack (beta), Static, Dockerfile, Docker Compose, plus Docker Image pulls | Nixpacks (default), Railpack, Dockerfile, Heroku Buildpacks, Paketo Buildpacks, Static | herokuish, Cloud Native Buildpacks, Dockerfile, Nixpacks, Railpack, Lambda or null builders |
| Managed databases | PostgreSQL, MySQL, MariaDB, MongoDB, Redis, Dragonfly, KeyDB, ClickHouse | PostgreSQL, MySQL, MariaDB, MongoDB, Redis | None by default; official plugins add Postgres, MySQL, MariaDB, Redis, Mongo and others |
| Scheduled database backups | PostgreSQL, MySQL, MariaDB, MongoDB and ClickHouse; not Redis, Dragonfly or KeyDB | Automated backups to S3 destinations; confirm schedule and retention options per database | Scheduled backups to S3-compatible storage through the dokku-postgres plugin; confirm for other plugins |
| Preview deployments | Pull and merge requests from GitHub, GitLab, Gitea and Bitbucket; needs wildcard DNS | Documented; confirm supported Git providers and how wildcard DNS is handled | Not covered by supplied facts; confirm with the Dokku docs and your CI setup |
| Multi-server model | Connects to each server over SSH and deploys to it; each server runs a coolify-proxy container | Docker Swarm manager and worker nodes; needs a Docker registry; vertical scaling recommended first | Single server by default; k3s scheduler builds a multi-server cluster but needs a registry |
| Paid options | Self-hosted edition is free with all features; Coolify Cloud is hosted and billed per server | Hobby and Startup plans; Enterprise with SSO/SAML, SCIM, audit logs and an SLA by quote | Dokku Pro offered at pro.dokku.com; confirm scope and pricing with the vendor |
| Default proxy | Traefik by default; Caddy as an alternative; Custom (None) leaves routing and TLS to you | Traefik on ports 80 and 443 with the web interface on port 3000 | Confirm the default proxy and TLS setup in the Dokku proxy management docs |
What each license and paid tier allows you to do
Coolify's repository is licensed under Apache-2.0, and its Coolify pricing page describes the self-hosted edition as free forever with all features and no limitations or restrictions. Coolify Cloud is a separate paid service in which Coolify hosts the management instance on its managed infrastructure, while you still connect and pay for your own servers.
- Self-hosted edition: the software carries no license fee under the pricing page's description, so your costs are the servers, storage, backups and the people who operate them.
- Coolify Cloud base price: $5 per month for 2 connected servers.
- Additional servers: $3 per month for each server beyond the first two, with a 20% discount for annual billing.
- Who pays for what: Coolify Cloud hosts the control plane for you, but patching, securing and backing up the application servers and their data remains your job.
- Recurring versus one-time: self-hosting has no recurring license line, while Cloud recurs monthly or annually and rises with server count.
Before committing, confirm the current pricing page and the Apache-2.0 license text, and ask whether any paid support exists beyond the free edition, because the sources supplied for this page do not describe support terms.
Dokploy uses a split license. Its LICENSE.MD applies the Apache License 2.0 to all code outside /proprietary directories, while code inside them falls under the Dokploy Source Available License 1.0. The proprietary components are not OSI open source, so an Apache 2.0 label on the project does not cover them.
- Apache 2.0 core: the code outside /proprietary can be used, modified and redistributed under Apache 2.0 terms.
- Proprietary components: the /proprietary code includes SSO with OIDC and SAML, SCIM, audit logs, custom roles and license key handling, and it allows production use only under a commercial agreement with Dokploy.
- Resale restriction: TERMS_AND_CONDITIONS.md calls the core free and open source, but forbids commercial resale or redistribution of Dokploy as a service without explicit consent from the Dokploy team.
- Published tiers: Hobby is listed at $4.50 per month per server (1 server, 1 organization, 1 user). Startup starts at $15 per month for up to 3 servers with basic RBAC. Enterprise, cloud or self-hosted, adds SSO/SAML, SCIM, audit logs and an SLA at contact-sales pricing.
- Who pays for what: the Enterprise features, SLA and the commercial production terms are priced by quote, so the license cost depends on the agreed scope.
Before relying on any identity or audit feature, confirm which directory it lives in and whether your intended use needs a commercial agreement under the source-available terms.
Dokku is MIT licensed, and its LICENSE file carries a 2014 copyright by Jeff Lindsay. The core therefore carries a permissive license with no split between open and proprietary directories in the core repository. The project's latest release, v0.38.31, was published on September 27, 2026, and the project is still versioned 0.x.
- MIT license: the core can be used, modified and redistributed under permissive terms, with the copyright notice kept in copies.
- 0.x versioning: the project has not reached a 1.0 release, so read the release notes carefully before each upgrade and test upgrades on a non-production host.
- Dokku Pro: the project lists Dokku Pro at pro.dokku.com as a separate offering. The sources supplied for this page do not describe its features, terms or price, so ask the vendor directly.
- Plugins: official plugins such as dokku-postgres live in their own repositories, so check each plugin's license and maintenance status separately from the core.
- Who pays for what: the core carries no license fee under its MIT terms, so your costs are the single server, its operation and any support you buy from a third party or from Dokku Pro.
Before adopting Dokku in a regulated environment, confirm the license of every plugin you install and document which upgrade path you will follow across 0.x releases.
What running each platform asks of your team
The first operating question is the host. Coolify lists at least 2 CPU cores, 2 GB RAM and 10 GB of free disk, on Linux only, and its installer runs a single script. Dokploy lists at least 2 GB RAM and 30 GB of disk, and its installer sets up Docker Swarm, publishes Traefik on ports 80 and 443 and serves the web interface on port 3000. Dokku's default docker-local scheduler needs 1 GB RAM on Debian 11 or later or Ubuntu 22.04, 24.04 or 26.04. For Coolify, the main hands-on work is different: it connects to each server over SSH and prepares it to run Docker workloads, so the team must decide who holds those SSH keys and how access to the control instance is restricted. In every case, your team owns the host operating system: patching, kernel updates, Docker versions and disk growth remain yours unless a retainer says otherwise. Confirm the supported distribution list against your own OS standard before you commit.
Backups are where the burden is easiest to underestimate. Coolify's scheduled backups cover PostgreSQL, MySQL, MariaDB, MongoDB and ClickHouse, but not Redis, Dragonfly or KeyDB, so any cache or queue with state needs its own plan. Dokploy offers automated backups to S3 destinations configured in its settings, and the dokku-postgres plugin runs one-off or scheduled backups to S3-compatible storage. Design the retention policy, the bucket credentials, a restore test and the location of the backup host before go-live. Upgrades carry their own cost. Coolify v4.0.0 was the first stable release, and its notes preview a v5 aimed at scalability in the core while v4 stays supported, so ask how a major version move would be tested against your apps. Dokploy and Dokku are both on 0.x version numbers, which the reader should weigh when planning upgrade windows.
A quote should separate five cost components: initial installation, hardening, backup design, upgrades and support retainers. Installation is usually the smallest and most predictable item. Hardening covers SSH access, firewall rules, proxy TLS settings and the choice of Traefik or Caddy, or the Custom (None) option that leaves routing and certificates to your team. Backup design and restore testing recur whenever the database inventory changes. Upgrades and support retainers recur on a calendar you set. Ask the provider to state in writing which of these items are one-time, which recur, and which assume your team performs the work. DeployOpen does not publish a price list, so the quote should follow from the written scope.
When a team should move to Kubernetes instead
A team should consider leaving the PaaS layer when the deployment model stops matching the workload, not because a platform looks dated. The clearest signals are many services that must scale independently, deployments spread across several clusters, a need for GitOps with reconciliation from Git, or stateful databases that require operator-managed high availability. Argo CD and Flux are both Apache-2.0 and were graduated in the CNCF on December 6, 2022 (Argo) and November 30, 2022 (Flux), and they assume a Kubernetes control plane. For database failover, CloudNativePG is an Apache-2.0 CNCF Sandbox operator that uses the Kubernetes API server for failover, which only makes sense once the team already runs Kubernetes.
Each self-hosted PaaS covers part of this ground. Dokku's k3s scheduler builds a multi-server cluster, but only the initial Dokku server is the git push target, and it requires a Docker registry. Dokploy's clusters use Docker Swarm manager and worker nodes, and its own documentation recommends vertical scaling first because horizontal scaling needs more configuration. Coolify manages many servers over SSH, yet it places each application on servers it manages rather than scheduling pods across a shared control plane. Ask each vendor how a stateful service, a rolling upgrade across nodes and a cluster-wide policy would behave under your load, and test those cases before you commit.
Moving is a platform change, not a configuration change. It adds cluster lifecycle, certificate and ingress design, storage classes, RBAC and an upgrade cadence to the team's work, and it changes who gets paged. Confirm in your own environment which Kubernetes distribution, control plane layout and etcd backup routine you will run, and whether your staff already operate those components. Run a pilot with one non-critical service and measure the operating hours it takes before you move the rest. Keep the PaaS running in parallel until the new platform has survived a full upgrade cycle.
How to pilot a self-hosted PaaS before you commit
This sequence turns a shortlist of Coolify, Dokploy and Dokku into evidence you can take to legal, security and operations before you commit. Each step ends with a written output, so the decision rests on your own workloads rather than on feature pages.
Inventory the apps, databases and servers in scope
The platform engineering lead lists every application, database and host the platform would run, along with each one's build method, data store, backup requirement and whether it is public-facing. Include preview environments if developers expect them, since preview builds depend on Git provider integration and wildcard DNS. The step is done when the list is signed off by the application owners and names the number of servers each workload needs. This list becomes the test plan for every later step.
Shortlist one option per deployment pattern
Using the inventory, the architect matches each workload to a deployment pattern: a single server with Git push and a small app set, a managed-style UI across several SSH-connected servers, or a path toward Kubernetes. Coolify, Dokploy and Dokku are not interchangeable here. Dokku runs on a single server by default and its multi-server option uses K3s, while Coolify manages several servers over SSH and Dokploy's clusters use Docker Swarm. The output is one named candidate per pattern, with the reason written beside it.
Run a pilot with one Git app, one database and one restore
On a non-production server that matches your minimum hardware and operating system requirements, the platform engineer deploys one application from a Git repository, provisions one database and configures one scheduled backup to your S3-compatible target. The pilot then restores that backup to a separate test host using the platform's restore path, and the team checks row counts and application behavior. Confirm the exact backup formats and retention options in the vendor documentation before you start. The step is done when the restored database serves the application on the test host.
Review license terms and proprietary components with legal
Counsel reviews the license file, terms of service and any commercial agreement for each shortlisted product, and flags anything that governs production use, resale or hosting for others. Dokploy is the case to examine closely: its repository applies Apache 2.0 to most code but sets a separate source-available license for enterprise features such as SSO, SCIM and audit logs. Ask each vendor in writing which features you would need in production and under which license they fall. The output is a signed memo naming the license that governs each feature you plan to use.
Log every operating task the pilot exposed
The operations team keeps a running log of each manual task the pilot required, such as proxy and TLS configuration, server preparation, registry setup for multi-server clusters, backup verification, upgrades and log access. Record who performed each task, how long it took in your own environment, and which steps the team could not complete without vendor documentation. This log is the basis for estimating ongoing effort, because it captures the work that will recur after go-live. The step is done when the log covers every workload in the inventory.
Decide whether to keep the platform or plan a Kubernetes move
The steering group compares the pilot log against the inventory and decides whether the chosen platform can carry the workloads, or whether the team should plan a move to Kubernetes. Choose Kubernetes when workloads need features the PaaS does not offer, when the number of servers or the scheduling needs outgrow the platform's model, or when the team already runs Kubernetes. Record the decision, the trigger conditions for revisiting it and the questions to put to the vendor or implementation partner. The output is a written decision with its evidence attached.
Questions buyers ask about self-hosted PaaS cost, effort and support
Do Coolify and Dokku cost anything to license?
Neither project charges a license fee for the self-hosted edition. 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. Dokku is MIT licensed. Your costs are the servers, the storage, the staff time to run the platform and any outside help you buy. Coolify Cloud is a separate paid service, priced at $5 per month for 2 connected servers plus $3 per month for each additional server, according to Coolify's pricing page, with a 20% discount for annual billing. Confirm current terms on the vendor pages before you budget, since prices can change.
Is Dokploy free to run in production?
Dokploy's core code is Apache 2.0, but its pricing page lists paid tiers. Hobby is $4.50 per month per server for 1 server, 1 organization and 1 user. Startup starts at $15 per month with up to 3 servers and basic RBAC, according to Dokploy's pricing page. Enterprise, cloud or self-hosted, adds SSO/SAML, SCIM, audit logs and an SLA at contact-sales pricing. The proprietary directories are covered by the Dokploy Source Available License 1.0, which allows production use only under a commercial agreement. If you need SSO or audit logs, read LICENSE_PROPRIETARY.md with counsel before you deploy.
What drives the cost of an implementation project?
The main drivers are scope, the number of apps and services, the backup design, SSO integration and hardening. A single-server setup with a few apps is a different job from a multi-server cluster with managed databases, preview environments and identity integration. Backups are often underestimated: Coolify's scheduled backups cover PostgreSQL, MySQL, MariaDB, MongoDB and ClickHouse but not Redis, Dragonfly or KeyDB, so the design must cover each data store. Ask any provider for a written scope listing the apps, databases, environments, identity provider, backup targets, restore tests and handover documentation. DeployOpen agrees scope, deliverables and timelines in writing before work starts, and quotes follow from that scope.
Can a team run these platforms without outside help?
Yes, a team with Linux administration, Docker and a basic understanding of DNS and TLS can run any of the three tools. Coolify installs with a single script and needs at least 2 CPU cores, 2 GB RAM and 10 GB of free disk, according to its installation docs. Dokploy needs at least 2 GB of RAM and 30 GB of disk. Dokku runs on a single server with 1 GB of RAM for its default scheduler. The harder parts are ongoing: patching the host, rotating credentials, restoring backups on a schedule and upgrading the platform. Outside help is most useful for the first design, the identity and backup work and periodic upgrade windows.
How long does a migration from Heroku, Vercel or Render take?
The duration depends on the number of apps, the volume of data to move, how many environment variables and secrets need rebuilding, and how much of each app depends on managed-platform features. Migrating a few stateless apps is short work. Moving production databases, custom domains, cron jobs and CI pipelines takes longer, and the data move needs a tested cutover plan. Dokku's app.json support covers deploy scripts, cron tasks and healthchecks, but its documentation notes that not all Heroku functionality is supported, so each app needs a check. Ask for a written migration plan with a per-app inventory before you agree a timeline.
What staff skills and on-call coverage does a self-hosted PaaS need?
Plan for at least one engineer who can administer Linux, Docker and the reverse proxy, plus a second person who can restore from backup when the first is away. The platform runs on your servers, so host outages, disk exhaustion, certificate renewal failures and failed backups become your incidents. Coolify's proxy runs one container per server, and Dokploy's installer sets up Docker Swarm, so your team must understand those layers. Define who receives alerts, what the escalation path is and how often restores are tested. Ask any partner which of these tasks are included in the engagement and which remain with your staff.
When does a retainer for upgrades and support make sense?
A retainer fits when your team cannot absorb regular upgrade windows, security patching and on-call response on its own. It also suits platforms that carry revenue-critical apps. Upgrade timing matters: Coolify's v4 remains supported while v5 is previewed, Dokploy's paid tiers add SLA terms at the Enterprise level, and Dokku is still versioned 0.x. Ask for the response scope, which versions are covered, how backups are verified and whether testing is continuous or periodic. DeployOpen offers ongoing support, upgrades and continuous testing as retainers, and most engagements are fixed-scope before any retainer begins.
How DeployOpen scopes a self-hosted PaaS selection and rollout
DeployOpen plans, implements, integrates, hardens, documents and supports self-hosted open-source platforms inside the client's own infrastructure. For a self-hosted PaaS decision, the work starts with a written scope that covers which platform fits the workloads, where it will run and who will operate it.
How we scope
- Map which applications, build methods and databases the team needs to deploy before naming a platform.
- Confirm the target hosts, cloud accounts or air-gapped networks where the platform will run.
- Agree in writing the scope, deliverables and timeline before any work begins, since most engagements are fixed-scope.
How we build
- Install and configure the chosen platform on the client's own servers, with the proxy, TLS and access settings agreed in scope.
- Set up database backups to the client's S3-compatible storage and test restores before go-live.
- Integrate build pipelines, Git providers and preview environment DNS with the existing identity and network setup.
How we hand over
- Document the architecture, server inventory, deployment runbooks and backup and restore procedures in the client's language.
- Walk the client's operators through routine deployments, scaling, upgrades and incident steps before handover.
- Record the licensing terms, paid features and any commercial agreements in use, so the team can confirm them later.
How we support
- Offer ongoing support, upgrades and continuous testing as a retainer after the initial rollout.
- Review platform release notes and support windows with the client when a version approaches end of support.
- Re-test the platform and its exposed applications on a schedule agreed in the retainer scope.
