Dora NodaOn January 21, 2026, Dokploy replaced its "Apache 2.0 with appendix" license with a clean, OSI-recognized Apache 2.0 for its core. The old file told you that you could use the software under Apache 2.0 — and then, in the next paragraph, told you that you could not sell it, could not redistribute a paid version, and could not profit from distributing it without written permission. The new file does not. That delta is the entire story for anyone picking a self-hosted PaaS on trust.
For a buyer comparing "open source" self-hosted PaaS options on more than a feature checklist — who can fork it, who can sell it, who can walk it back next year — Dokploy's switch is good news that also proves the problem it claims to solve. A competitor standardizing on your own license twelve months after you did does not erase the twelve months it spent with the ambiguous one, and "we fixed it" is a weaker trust claim than "we never needed to fix it" will ever be.
Here is the concrete before-and-after that the January 21 commit actually delivered, before we draw any conclusions from it:
| Dimension | Before: Dokploy pre-Jan 21, 2026 (Apache 2.0 + Appendix) | After: Dokploy from Jan 21, 2026 (core Apache 2.0; proprietary/ under DSAL) |
|---|---|---|
| Core license file | LICENSE.MD = Apache 2.0 text + Appendix and Appendix B that supersede it on conflict | LICENSE.MD = unmodified Apache 2.0; plus LICENSE_PROPRIETARY governing only proprietary/ directories |
| Commercial resale / SaaS distribution | Prohibited without prior written consent: "no party is permitted to sell, resell, or otherwise distribute for commercial gain... through any form of commercial distribution channels, including SaaS" | Permitted for core under Apache 2.0 (patent grant, no field-of-use restriction). Proprietary directories remain source-available-only |
| Redistributing a paid / modified version | Prohibited: "no persons are permitted to redistribute another paid version" or "create the same paid version" | Permitted for core; proprietary features (SSO/SAML, fine-grained RBAC, audit logs, white-labeling) excluded from that permission |
| Modifying free vs paid features | Free-feature mods must be distributed "as free & open source"; paid-feature mods prohibited entirely | Free-feature rule removed for core; proprietary code stays non-modifiable/non-redistributable under its own terms |
| OSI-recognized? | No — the appendix adds a field-of-use/commercial restriction that fails the Open Source Definition | Core yes (plain Apache 2.0). Repository as a whole is now marketed as "Apache 2.0 core + Source Available for enterprise features" |
| Who decides what is "paid"? | Appendix language alone (ambiguous scope across the repo) | File-system boundary: if it is under proprietary/, DSAL applies; otherwise Apache 2.0 |
| Fork that is entirely Apache 2.0? | Not without stripping the appendix (which claimed to supersede Apache 2.0 on conflict) | Now possible by deleting proprietary/ — forks like Crane (ghaaf-labs/crane) do exactly this |
Sources: new LICENSE.MD fetched from Dokploy/dokploy@canary on August 16, 2026 (dual-notice structure quoting proprietary/ and LICENSE_PROPRIETARY); old LICENSE.MD at commit be56ba0 (Apache 2.0 plus "Prohibition of Resale Without Permission" and paid-feature appendix); third-party descriptions of the January 21, 2026 effective date and DSAL scope in Cloudzy and Deploynix comparisons.
That table is the deliverable. Everything else in this post is what it means.
What the old license actually said — and why "Apache 2.0 with an asterisk" was not Apache 2.0
Dokploy shipped for most of its early life under a license file that began like a standard Apache 2.0 grant and then added two appendices that said, in effect, "unless we say otherwise."
The appendix text at be56ba0 was not subtle:
"In case of a conflict, the terms of this appendix supersede the general Apache License."
Three bullets followed — do not modify paid features, do not redistribute another paid version, do not create the same paid version — and Appendix B added a broad commercial-distribution prohibition: no selling, reselling, or distributing "for commercial gain" through SaaS, marketplaces, or physical media without a separate commercial agreement.
That is not an interpretation of Apache 2.0. It is a rewrite of its core guarantee. The Apache License 2.0 is a permissive license precisely because it does not restrict fields of use — commercial use, SaaS hosting, resale, and modification are all permitted, with only attribution, patent-grant, and NOTICE-file obligations retained. An "Apache 2.0, but you may not use this as a paid service" clause fails clause 6 of the Open Source Definition (no discrimination against fields of endeavor) and would not pass any OSI review. Community trackers such as the open-source-confusion-cases listing for Dokploy flagged it on exactly those grounds, calling it "Apache 2.0 with strong non-open added terms."
The practical effect was ambiguity where a buyer needs certainty:
- A team evaluating Dokploy could not answer "can we host this for a customer and charge for it?" from the license alone without lawyering the appendix.
- A team that had already deployed could not answer "what happens if a feature we rely on is declared 'paid' tomorrow?" because the boundary between free and paid was defined in prose, not in the repository layout.
- A team comparing vendors could not line up Dokploy next to Coolify (plain Apache 2.0 since inception, ~57,000 stars by mid-2026) or CapRover (plain Apache 2.0) and treat the word "open source" as meaning the same thing in both rows.
Dokploy was not alone in this pattern. The same custom-terms trick — start with a known license name, append a commercial restriction — has appeared across "open source" infrastructure tools that want the trust signal of a familiar license without the commercial freedom that makes the signal mean something. It is why buyers who have been burned before now read the appendix before they read the README.
What January 21 actually standardized
The January 21, 2026 change is structurally small and legally large. The repository's license file now reads: "All content under /proprietary is under LICENSE_PROPRIETARY; everything else is Apache 2.0." That replaces a repo-wide appendix with a directory boundary.
Three consequences follow:
1. The core is now unambiguously permissive. Anything outside proprietary/ — the deploy engine, Docker/Traefik orchestration, database provisioning, the dashboard that most self-hosters actually run — is plain Apache 2.0. You can use it commercially, modify it, distribute it, and offer it as a service without negotiating a separate agreement. The patent grant and disclaimer from upstream Apache 2.0 apply without an overriding appendix.
2. The non-open part is now explicitly non-open, not disguised as open. Code under proprietary/ is governed by the Dokploy Source Available License (DSAL). Third-party summaries describe its current scope as future enterprise features — SSO/SAML, fine-grained RBAC, audit logs, white-labeling — the exact features a team selling Dokploy-as-a-service would need to gate. A separate source-available license is not an open-source license, and Dokploy no longer claims otherwise. That honesty is the fix.
3. A fully Apache 2.0 build is now a rm -rf away. Forks that want a single-license artifact can delete proprietary/ and ship the remainder as Apache 2.0. That is not theoretical. The Crane fork (ghaaf-labs/crane, hard-forked from Dokploy v0.29.6) advertises itself as "Apache-2.0 hard fork — removes the upstream open-core /proprietary (DSAL) layer" and a second fork, Docklands, carries the same note: "Upstream source-available/proprietary components have been removed rather than rebranded." In other words, the new structure is enforceable at the file-system level in a way the old appendix never was.
Comparison writeups since the switch describe Dokploy's current position accurately: "Effective January 21, 2026, Dokploy's core is standard Apache 2.0. A separate Dokploy Source Available License now governs code in proprietary/ directories, currently scoped to future enterprise features." The same writeups put the caveat plainly too: "licensed Apache-2.0 while introducing a separate source-available license for future paid features — worth reading if license purity matters to you." Both halves matter. The first is what changed. The second is what did not.
Against peers, the shape of mid-2026 self-hosted PaaS licensing now looks like this:
| Project | License structure (mid-2026) | Core is plain Apache 2.0? | Enterprise gate |
|---|---|---|---|
Coolify (coollabsio/coolify) | Apache 2.0, whole repo | Yes, since inception | None — same license for all features |
| CapRover | Apache 2.0 / MIT family (per repo) | Yes | None gated by license |
| Dokploy (post-Jan 21) | Apache 2.0 core + DSAL for proprietary/ | Yes (new) | proprietary/ (SSO, RBAC, audit, white-label) |
| Bex.co | Apache 2.0, whole repo | Yes, from day one | None gated by license |
| Dokploy (pre-Jan 21) | Apache 2.0 + appendix superseding it | No — appendix prohibited commercial SaaS distribution | Ambiguous (repo-wide prose) |
Coolify's Apache-2.0 claim never needed a migration note. Bex.co's never did either. Dokploy's now holds — but only with a second row in the table that did not exist before.
Why a late migration is not the same claim as starting there
Dokploy fixing its license is good for its users. It is also, by definition, evidence that a weaker license preceded it. That matters more than any feature delta, because licenses encode incentives and incentives are what a buyer is actually betting on.
The relicensing tax. Every team that evaluated Dokploy before January 2026 did so under the appendix. Contracts, procurement checklists, and legal approvals from that period reference the license that was on HEAD at the time. A retroactive change does not retroactively re-approve those decisions. One team that pinned an older Dokploy version now has to answer whether its deployed artifact was ever covered by the clean license (it was not — version pinning freezes the license that shipped with that version), and a team that evaluated Dokploy and walked away over the appendix has to re-run the evaluation it already paid to run once.
The ambiguity residue. An appendix that claimed to supersede Apache 2.0 on conflict leaves a question no single commit fully erases: what other interpretations did that appendix license, explicitly or implicitly, while it was the governing document? Forks, marketplace listings, or service offerings created under the old text do not automatically become compliant because the upstream changed its mind — they complied (or not) with what was on file when they were created. "We standardized on Apache 2.0 in January" is a forward-looking statement. It does not rewrite the year-plus of commit history during which the appendix applied.
The ease-of-matching illusion. A competitor can match Bex.co's license line in a README in one commit. It cannot match the claim "we have been plain Apache 2.0 since the first commit" without having been plain Apache 2.0 since the first commit. That second claim is not marketing — it is falsifiable by reading git log --diff-filter=A -- LICENSE*. Bex.co's repositories invite exactly that audit: every early tag carries the same unmodified Apache 2.0 that the current tag does. There is no migration commit to find, no appendix to have removed, no DSAL directory that postdates the choice. A buyer who treats "same license today" as "same trust story" is conflating a snapshot with a history.
The open-core boundary still exists. Dokploy's new structure is honest, but it is still open-core. A directory called proprietary/ governed by a source-available license is a real boundary with real consequences: any feature that moves into that directory leaves the Apache-2.0 side in the next release. Contributors, self-hosters, and commercial re-distributors now have a clear line to watch — which is an improvement over the old " Appendix says paid features are whatever we say they are" — but they still have a line to watch. Coolify and Bex.co, as of mid-2026, have no such directory. Whether that matters for a given buyer depends on which features they need, but the structural difference is not erased by the word "core" in "core is Apache 2.0."
None of this is an argument that Dokploy's change was cosmetic. It was not. Moving from a repo-wide appendix that prohibited SaaS redistribution to a clean Apache 2.0 core with a directory-scoped DSAL is a material narrowing of the restriction and a material gain in clarity. It is an argument that clarity gained retroactively is not the same signal as clarity that never needed gaining.
A five-point checklist before you trust any "open source" PaaS badge
If you are choosing a self-hosted PaaS and the word "open source" is on the shortlist of reasons, read the following before you read the feature matrix. Every row is checkable in under ten minutes against the repository you are about to deploy.
1. Open the license file at HEAD and at first commit. LICENSE, LICENSE.md, LICENSE.MD — whichever exists. Is it verbatim Apache 2.0 / MIT / BSD with no appendix that says "in case of conflict, this appendix wins"? Then run git log --follow -- license* (case-insensitive) and read the first version. If the first version already matches HEAD, there was no migration. If there is a migration commit (like Dokploy's January 2026 standardization), read its diff — that is the real scope of the change.
2. Check whether the OSI would agree. Paste the license name into the OSI's approved-license list. "Apache 2.0" passes. "Apache 2.0 with Commons Clause," "Apache 2.0 with Appendix B — Prohibition of Resale," or "Apache 2.0 for the core, Proprietary for proprietary/" does not — at least not as a single license. A product can be "Apache 2.0 core + DSAL for enterprise" and be honestly described that way, but that description is not the same claim as "Apache 2.0" full stop. Know which one you are buying.
3. Map the boundary, not just the label. If the repo uses a dual structure (proprietary/, ee/, enterprise/), list what is inside it today and how much of the roadmap the maintainers say will enter it next. Dokploy's current answer — proprietary/ holds SSO/SAML, RBAC, audit logs, white-labeling — is a small, documented surface. A credible answer names the directory and the feature set and never requires you to guess whether last week's feature moved across the boundary.
4. Ask who can relicense, and how. Under Apache 2.0, contributors retain copyright but grant a permissive license. Only the copyright holder(s) can relicense future versions. Check NOTICE, CONTRIBUTORS, and the contributor license agreement (CLA) if one exists. A project with a centralized CLA and a single commercial entity behind it can legally relicense tomorrow with no contributor vote; a project with distributed copyright cannot. Neither outcome is inherently bad — but only one of them makes "we will always be Apache 2.0" a promise the community, rather than a single company, backs.
5. Run the fork test. Can you delete the non-open directories, keep the brand-neutral name, and ship the remainder as a useful product under the advertised open-source license? Dokploy now passes a weak version of this test: delete proprietary/ and the rest is Apache 2.0 (Crane and Docklands demonstrate it). Bex.co and Coolify pass the strong version: there is nothing to delete. CapRover has passed it since before any of these projects existed. If the answer is "only if you also remove the feature you actually need," the open-source label does not cover your use case no matter what the README says.
What to do with Dokploy's fix
Dokploy did the right thing on January 21. A year ago its license file said "Apache 2.0, but not really" — commercial SaaS redistribution required permission, paid features could not be modified or redistributed, and the appendix won any conflict with the license it appended to. Today its core says "Apache 2.0, period" and its non-open code is confined to a directory that says so on its face. For a solo operator or a small team that deploys the core as-is, the practical difference is that a class of legal ambiguity that used to require a lawyer now requires only ls proprietary/.
That does not, by itself, make "open source PaaS" a commodity label where every project that advertises Apache 2.0 in mid-2026 sits on equal footing. A year of ambiguity, a retroactive standardization, and an ongoing open-core boundary are part of the artifact in a way that starting plain Apache 2.0 from the first commit is not. Trust in a license is trust in the party that chose it, and a party that chose the restrictive version first and the clean version second has told you more about its incentives — and asked you to re-verify more — than a party that chose the clean version once and never had to walk it back.
If you are evaluating self-hosted PaaS options right now, pull the three license files, run the five checks above, and decide which history you want to audit next quarter. And if you are building the platform yourself, pick the license you intend to keep at the commit where someone can first read it. Retroactively becoming what you could have started as is always possible. Retroactively having started as it is not.
Bex.co is the open-source, AI-native Render alternative — push a git repo, get a running HTTPS service on machines you own. The entire platform is Apache 2.0 from the first commit, with no proprietary directory and no commercial-use appendix to read around. Star the repo on GitHub or deploy your first app today.