Dora NodaBoth Coolify and Dokploy call themselves open-source, self-hosted Heroku alternatives. Both wrap Docker in a web UI with git-push deploys and HTTPS by default. Both are free to install on a five-dollar VPS. And if you are a solo developer deploying your own apps, the licensing difference between them will never touch you.
But if you are an agency — if your business model is charging clients for managed hosting — one of these two licenses covers everything you do, and the other one draws a line straight through the middle of your product. The line is not in the feature matrix. It is in the license file, and it moved once already this year. Here is the verdict up front, with the receipts below.
| Coolify | Dokploy | |
|---|---|---|
| Core license | Apache 2.0, whole repo | Apache 2.0 outside proprietary dirs |
| Restricted code | None — no gated code in the repo | Proprietary dirs under the Dokploy Source Available License (DSAL) v1.0 |
| Production use of restricted code | n/a (nothing restricted) | Requires "a valid commercial agreement from Dokploy" |
| What's currently restricted | — | SSO/SAML/OIDC/SCIM, audit logs, custom RBAC roles, license keys, whitelabeling |
| Fork it, resell hosting on it | Yes, unambiguously | Core yes; the enterprise wrapping (SSO, whitelabel, audit logs) needs a paid agreement |
| Solo dev, own apps | Fine | Fine |
| Agency selling managed client hosting | Fine, zero license diligence | Fine only via Dokploy Cloud/Enterprise — or scoped to the Apache core without the gated features |
That table is the whole post in miniature. The rest is why each cell says what it says, and how to check it yourself in ten minutes.
Open source has a definition, and it has teeth
"Open source" is not a vibe. The Open Source Definition's sixth criterion — no discrimination against fields of endeavor — says the license "must not restrict anyone from making use of the program in a specific field of endeavor," and names commercial use explicitly (opensource.org/osd). A license that says "free for personal use, contact us for commercial use" fails this test on its face.
That failure has a name: source-available. You can read the code, but you do not have the freedoms the term "open source" promises. This distinction is the entire lens for this post. When a self-hosted PaaS says "open source," the question is never "can I see the code" — it is "which directories can I build a business on, and what does the license file at the commit I deploy actually permit." Hold that thought, because one of our two projects changed its answer in January 2026.
Coolify's license, precisely
Coolify's case fits in one sentence: the repository's LICENSE file is the unmodified Apache 2.0 text, covering the whole tree (coollabsio/coolify LICENSE). There is no enterprise edition in the repo, no gated directory, no second license file. Self-hosted Coolify is the full feature set, free forever, and the optional Coolify Cloud (about $5/month base for a managed control plane pointing at your own servers) is a hosting convenience, not a feature unlock (Coolify Pricing Teardown 2026).
Apache 2.0 permits commercial use, modification, distribution, and sublicensing, with a patent grant, in exchange for preserving notices. Concretely for an agency: you may fork Coolify, rebrand it, run a fleet of client workloads on it, and charge for the managed service — no permission needed, no revenue share, no per-server meter running. That is what "100% Apache 2.0" buys, and it is why every 2026 head-to-head that reaches the licensing row scores it the same way (Cloudzy comparison, NextGrowth head-to-head).
Dokploy's license, precisely
Dokploy's story has two eras, and you need both, because most of what you'll read online describes Era 1 while the repo you clone today is Era 2.
Era 1 (2024–2025): the per-feature resale restriction. The old apps/dokploy/LICENSE.MD layered extra provisions on top of Apache 2.0, with an explicit precedence clause. The operative sentence was the "Restriction on Resale": multi-node support, Docker Compose file support, Preview Deployments, and Multi Server "cannot be sold or offered as a service by any party other than the copyright holder without prior written consent." A community issue asking for a stripped-down fully-open version enumerated the same set plus Schedules (dokploy/dokploy#3477), and an earlier issue had already argued the project should stop presenting itself as Apache-licensed at all (dokploy/dokploy#82). Note what was gated: not cosmetic extras, but the scaling features — the multi-node and multi-server machinery a fleet operator needs.
Era 2 (January 2026 relicense, current): open core under DSAL. In January 2026 the project restructured to a directory-based split, which a June 2026 showdown flagged as worth reading "if license purity matters to you" (Deploynix showdown). The current top-level LICENSE.MD says everything outside a /proprietary directory is Apache 2.0, and everything inside one is governed by LICENSE_PROPRIETARY.md (LICENSE.MD). That second file is the Dokploy Source Available License v1.0, and its key sentence is blunt: the covered software "may only be used in production, if you (and any entity that you represent) have agreed to, and are in compliance with, a valid commercial agreement from Dokploy" (LICENSE_PROPRIETARY.md). Development and testing use is free; production is not.
What actually lives under /proprietary today? Verified against the repo tree at HEAD: SSO in all its forms (SAML, OIDC, SCIM, forward-auth, plus the social sign-in components), audit logs, custom RBAC roles, license-key management, whitelabeling UI, and the enterprise feature gate. The old per-feature resale file is gone — multi-node, compose, preview deployments, and schedules now sit under the Apache 2.0 core.
So the gate moved: Era 1 restricted the scaling layer, Era 2 restricts the enterprise layer. An agency's diligence has to target the current list, at the commit it deploys — which is exactly the habit the last section of this post teaches.
Why the restriction lands exactly on agencies
Map each era's restricted list onto buyer types and the pattern is stark.
A solo developer deploying personal projects on one VPS never triggers either era's restriction. You are not selling anything or offering anything as a service (Era 1), and your production use touches none of the proprietary enterprise code (Era 2) — you don't need SAML for your side project. This is why "Dokploy is effectively free for personal use" and "Dokploy restricts commercial use" are both true statements that confuse everyone: they describe different buyers.
A freelancer running one VPS per client, with each client paying for their own server and the freelancer charging for setup and maintenance, sits in the gray zone Era 1 created and Era 2 mostly clears — as long as no proprietary-gated feature is in the path. No whitelabeling, no client-facing SSO, no audit-log exports: the Apache core covers you. The moment a client asks "can our team log in with our identity provider" or "can the dashboard carry our logo," you've crossed into DSAL territory and need the commercial agreement.
An agency selling managed hosting as a product — your panel, your brand, client workloads billed monthly — sits squarely inside the restriction in both eras. In Era 1, the multi-node and multi-server features your fleet runs on were the restricted set. In Era 2, the enterprise wrapping your clients pay a premium for — whitelabeled dashboard, SSO for their org, audit logs for their compliance, custom roles for their team — is precisely the proprietary list. Your whole business model is "offered as a service," which is the exact verb the license regulates.
This is the sense in which the agency critique holds across both eras: whichever layer Dokploy puts behind the commercial gate, it is the layer an agency's business model needs. The compliant paths are straightforward — Dokploy Cloud (Hobby from $4.50 per server per month, Startup from $15 for three servers, per September 2026 pricing) or an Enterprise agreement including a self-hosted license key (Northflank comparison, prices checked Sept 10, 2026; Northflank on Enterprise Self-Hosted) — but they are paid paths, and the decision has to be deliberate rather than discovered during a client security review.
What independent testers concluded
Two practitioner verdicts, correctly timestamped, tell the story.
Shubham Soni's December 2025 comparison — a careful category-by-category test that ultimately picked Dokploy for his own production VPS — is explicit about the tradeoff: "Coolify is fully open-source under the highly permissive Apache 2 license. Dokploy is more complicated; while the core is Apache 2, code for key features like templates, multi-node support, and preview deployments is exempt and cannot be sold or offered as a service without consent." His conclusion: "Dokploy is effectively 'source available' rather than fully open source. For many, this will be the biggest reason to choose Coolify. It's a tough pill to swallow, but given Dokploy's better production experience for my needs, it's a compromise I'm willing to make." (Medium, Dec 2025).
Personal VPS: Dokploy. Client work: ruled out on licensing alone. That is the buyer split this post opened with, arrived at independently.
The August 2026 NextGrowth head-to-head, testing both panels on identical Hetzner VPSs, frames it as a decision tree: "Coolify's Apache 2.0 license removes any ambiguity. Dokploy's license requires you to verify what 'commercial use' means for your specific setup." (NextGrowth, updated Aug 12, 2026). Both pieces describe Era 1 text — but notice that the Era 2 relicense validates their advice rather than dating it. "Verify what commercial use means for your setup" is exactly the maneuver that catches a January relicense moving the gate from multi-node to SSO.
The practitioners who read the license file were robust to the license file changing. The ones who memorized a verdict — "Dokploy gates multi-node" — now hold a stale fact. Read the file, not the folklore.
The decision tree, by buyer
Solo dev, own apps on your own VPS. Either panel. The restriction never triggers for you in either era. Pick on product merits — UI preference, resource footprint, template library — and stop reading licensing posts.
Freelancer, one VPS per client. Either panel works if you stay disciplined, but the discipline differs. On Coolify there is nothing to stay disciplined about: the whole repo is Apache 2.0. On Dokploy, keep client setups on the Apache core — no whitelabeling, no SSO, no audit-log features — and re-verify the /proprietary list every time you upgrade, because the gate has moved once and the license file permits it to move again. The first client who needs SSO is your trigger to price in Dokploy Cloud or Enterprise.
Agency, managed hosting as a product. Two compliant options. Option A: Coolify, where the license question evaporates entirely — fork it, brand it, bill for it. Option B: Dokploy with a commercial agreement (Cloud or Enterprise self-hosted key) that covers the proprietary layer your product necessarily uses. What is not an option is Dokploy's proprietary features in production without that agreement — DSAL forbids it in plain language. If you're comparing "open source" panels on trust, this row is the whole comparison: one project has no trust-me layer, the other has a documented, priced one. Both are legitimate businesses. Only one of them lets you skip the license review.
Audit any "open source" PaaS in ten minutes
The Dokploy Era 1 → Era 2 move is the general lesson: license terms are versioned artifacts, and a verdict from last year is a rumor about this year's tree. Before you build a business on any self-hosted panel, spend ten minutes:
- Read the LICENSE file at the commit you deploy, not on the marketing page. Marketing says "open source"; the file says Apache, MIT, AGPL, SSPL, BSL, or "source available." Only the file counts.
- Grep for second licenses and gated directories:
proprietary/,ee/,enterprise/,LICENSE_*, and precedence clauses ("in the event of a conflict, these provisions shall take precedence"). Dokploy's split is directory-based; others gate by edition or feature flag — find the mechanism. - Check for production/commercial triggers: "commercial agreement," "offered as a service," "production use," per-server metering. Note exactly which features sit behind each trigger, then check whether your business model touches them.
- Re-run steps 1–3 on every upgrade. Licenses change under you — Dokploy's did in January 2026. Pin the license text alongside the version pin in your infrastructure repo so the next audit is a diff, not a rediscovery.
Start from the license file, not the feature matrix. The matrix tells you what the software does. The file tells you what you're allowed to build on it — and for an agency, that is the only feature that can't be worked around.
Bex.co is the open-source, AI-native Render alternative — push a git repo, get a running HTTPS service on machines you own. Star the repo on GitHub or deploy your first app today.
