Dokploy Is Apache 2.0 Again — But SSO, Audit Logs, and RBAC Now Live Behind a New Source-Available License

On January 21, 2026, Dokploy announced it was "updating its open source license." Read that headline on its own and it sounds like good news — and in one narrow sense, it is. But the actual change also did something the announcement didn't lead with: it created, for the first time, a formal /proprietary folder in the Dokploy codebase, governed by a brand-new Dokploy Source Available License (DSAL), that requires a paid commercial agreement before you can run its contents in production.

We pulled Dokploy's public GitHub tree directly rather than trusting secondhand summaries of the change, and the result is a precise, checkable list. As of this writing, 29 files sit under that /proprietary folder, covering five feature areas: audit logs, custom RBAC roles, SSO (SAML, OIDC, SCIM provisioning, and reverse-proxy forward-auth — plus, notably, GitHub and Google social sign-in), white-labeling, and the license-key engine that enforces all of it. Everything else — the deploy engine, multi-node/cluster support, Docker Compose deployments, templates, preview environments — stays Apache 2.0, unmodified, forever, per the maintainer's own on-record commitment. Here's exactly what changed, why it changed now, and what it means for "open source" as a claim self-hosted PaaS tools get to make.

What Actually Moved Behind /proprietary​

The new DSAL v1.0 text is short, and its core sentence is worth quoting exactly:

"This 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... you may copy and modify the Software for development and testing purposes, without requiring a subscription... it is forbidden to copy, merge, publish, distribute, sublicense, and/or sell the Software."

That license applies "only to the part of this Software that is in a /proprietary folder" — and walking that folder in the canary branch shows exactly what it covers:

That license-key engine isn't decorative. Per Dokploy's own developer docs, a running instance calls licenses-api.dokploy.com on demand and via a scheduled enterprise-check cron job every three days to re-validate an active key, returning a distinct LICENSE_SERVER_UNREACHABLE state if the check can't reach Dokploy's servers. Self-hosting a feature under DSAL still means depending on a Dokploy-controlled service to keep using it — the code lives on your box, but the permission to run it doesn't.

That's the practical distinction between "source-available" and "open source" that the DSAL text makes explicit. You can read every line in /proprietary, and — per the "free to modify for development and testing" clause — you can even fork and patch it locally without paying anything. What you can't do without a commercial agreement is run your modified version, or the original, in production. Contrast that with the Apache-licensed 95% of the codebase, where "read it, fork it, run it, sell services around it" all remain unconditionally true, no phone call to Dokploy required.

What Didn't Move​

It would be easy — and it's the version of this story a rushed summary tends to produce — to read "Dokploy went open-core" and assume the deployment engine itself got paywalled. It didn't. Confirmed still under the plain, unmodified Apache License 2.0:

• The core deployment engine and CLI
• Multi-node / cluster orchestration (Docker Swarm-based)
• Docker Compose project support
• The application template catalog
• Preview/ephemeral environments

If you're running Dokploy today to git-push deploy an app, put it behind a domain, and scale it across a couple of boxes, none of that changed on January 21. The five buckets above are additive, enterprise-tier features layered on top of a free core — the split is real, but it's narrower than "Dokploy" and "open source" being in tension across the whole product.

How Dokploy Got Here​

The current arrangement is actually Dokploy's second attempt at drawing this line, and the history explains why the new version is legally cleaner. In a long-running GitHub discussion opened in 2024, a community member (ssddanbrown) pointed out that Dokploy's original license wasn't really Apache 2.0 at all — it was a modified version of the Apache text with extra restrictions bolted on, covering an unclear set of "paid" features. Another commenter (sbuttgereit) noted that this ran directly into the Apache Software Foundation's own guidance: modify the license text and "the result is NOT the Apache License, just a new license inspired by ours." Calling a customized license "Apache 2.0" was, strictly, a mislabel.

Maintainer Mauricio Siu (Siumauricio) initially defended the approach, then narrowed it: by July 2024, only two specific features — Cluster and Compose support — carried restrictions, with everything else confirmed fully open. That was progress, but it left the same structural problem: a single license file doing two incompatible jobs, with the boundary between "free" and "paid" defined by prose rather than by the filesystem.

The January 2026 restructure fixes the mislabeling by fixing the mechanism. Apache 2.0 is now unmodified and applies to everything outside one folder; a separate, clearly named DSAL file applies inside it. Asked directly whether currently-free features could migrate into that folder later, Siumauricio's answer in the same thread was explicit: "what is kept in the open source version stays there." That's a commitment worth holding the project to, not a guarantee enforced by the license itself — DSAL governs the folder, not a promise about what enters it next.

The Open-Core Playbook, and Where Dokploy Sits on It​

Reserving a /proprietary (or equivalently named) folder behind a source-available license is a well-worn pattern, not a Dokploy invention. Elastic moved to SSPL, HashiCorp moved Terraform to the Business Source License (both partly in response to cloud providers reselling their software as a managed service without contributing back), and Sentry runs its own Functional Source License for similar reasons. GitLab has run a CE/EE split since long before any of those.

Dokploy's version is smaller in scope than any of those fights. There's no evidence a hyperscaler is reselling Dokploy as a managed service — the more direct read is that Dokploy wants to prevent a "DokployCloud" clone from packaging its own SSO/audit/RBAC work and reselling it, while still keeping the deploy engine itself fully open for the self-hosting crowd that is its actual user base. It's a defensible, common design; the point isn't that Dokploy did something unusual, it's that "open source" as a label now needs the folder-level caveat to be accurate.

What This Means If You're Already Running Dokploy​

If you're self-hosting Dokploy for the deploy engine, nothing changes: the license clarification doesn't touch anything you're currently running, and the maintainer's public commitment is that it won't. Where it matters is for teams that expect to grow into needing SSO, audit logging, or fine-grained roles — Okta/SAML integration for a security review, an audit trail for compliance, or a custom permission tier for a larger team. Those now come with a commercial-agreement requirement attached, by design, not as a surprise buried in a EULA.

Worth noting for anyone comparison-shopping: Coolify, the other name that comes up in every "self-hosted PaaS" thread alongside Dokploy, remains fully Apache 2.0 with no reserved proprietary carve-out as of this writing — a genuinely different answer to the same "how do we pay for this" question, not a better or worse one, just a different tradeoff for teams that specifically want SSO or audit logging without a license key.

That tradeoff cuts both ways, though. Dokploy's enterprise tier funds a maintained SSO/RBAC/audit stack that a team would otherwise have to bolt on themselves — reverse-proxy forward-auth, SCIM provisioning, and per-role permissions are genuinely nontrivial to build and keep patched. Coolify's fully-open approach means those integrations, if they exist at all, come from community contributions with no single vendor obligated to maintain them long-term. Neither structure is free; one bills you directly, the other bills you in maintenance hours.

Where That Leaves "Open Source" as a Claim​

Dokploy's January 2026 change is a net improvement in honesty over what came before it — a mislabeled modified-Apache license replaced with a standard one plus a clearly separated, clearly named alternative for the enterprise slice. That's a better state than the ambiguous 2024 version. But it's also a useful marker for the question every self-hosted tool eventually has to answer: does "open source" describe the whole product, or the product minus a folder?

bex is built on the other side of that line: one Apache-2.0 license, repo-wide, with no reserved /proprietary directory and no license-key server to phone home to. The source is on GitHub — push a git repo, get a running HTTPS service on hardware you own, under a license that doesn't need a footnote.

Sources:

• We are updating Dokploy's Open Source license — official announcement
• Dokploy LICENSE.MD — GitHub
• Dokploy LICENSE_PROPRIETARY.md (DSAL v1.0) — GitHub
• Dokploy /proprietary source tree — GitHub
• Queries regarding licensing and advertising as open source — GitHub Discussion #3
• License Keys & Enterprise Features — Dokploy DeepWiki
• Re: Apache 2.0 Sub-Licensing (Example: Dokploy) — Apache Foundation mailing list

All figures and quotes cited above are drawn directly from the linked sources.