Apache 2.0 PaaS Tools: What Open Core Really Promises

Dokploy published its own account of the change, and it is more specific than most of the coverage that followed. Until January it described an Apache 2.0 PaaS with extra terms attached. It replaced an adapted version of Apache 2.0, which it says caused confusion, with the unmodified licence for everything that exists today. Alongside it came a second licence, the Dokploy Source Available License, for future paid functionality.

The post is clear about where that second licence lives. Code outside directories named proprietary/ is Apache 2.0. Code inside them is source-available, meaning you can read, test and contribute to it, but using it in production requires a paid licence. The examples it gives are single sign-on and advanced access control, custom branding, high availability and auto-scaling, and advanced monitoring.

That is a promise about direction, and it is a good one. It is also a promise from a company, not a term of the licence. Keep that distinction in mind, because the rest of this piece is about the gap between the two.

Each row is a different kind of Apache 2.0 PaaS, or in Dokku's case an MIT one, and each is a different answer to the same funding problem. Dokku has no commercial layer on its page at all. Coolify sells a hosted convenience and leaves the self-hosted product whole. Dokploy keeps a free core and reserves a named category of features for paying organisations. If you want the longer version of the second, our Coolify review goes through what the free tier does and does not cover.

Safe for the code you already have, yes. An Apache 2.0 PaaS release carries a copyright licence that the text itself calls perpetual and irrevocable, so nobody can withdraw it from a release you downloaded, including the people who wrote it.

What the licence does not do is bind anyone to keep publishing. It says nothing about the next release, the next feature, or whether security fixes continue to land in the free repository. An Apache 2.0 PaaS project can stay Apache 2.0 forever and still move all of its momentum to a paid branch.

• Already released under Apache 2.0: yours to run, change and redistribute for good.
• Not yet written: governed by whatever licence the maintainers choose when they write it.
• Maintenance: a fork keeps the code alive, but somebody has to do the patching. For a 37,000-star project that is a real job, not a formality.

Source-available is the phrase people skim past. It means the code is readable. It does not mean you may run it. Dokploy's proprietary licence file is direct about production use.

The same file lets you copy and modify the software for development and testing without a subscription. So a developer can try SSO on a laptop and a team cannot switch it on in production without a contract. That is a fair line for the company to draw. It is also a line that a clone-and-deploy habit can cross by accident, which is why the checks below start with the licence file itself.

Our view: it is not a betrayal, and it is not a surprise. A free Apache 2.0 PaaS earns adoption by asking for nothing. Then the maintainers have users, support requests, security reports and hosted competitors, and no revenue tied to any of them. Something has to pay for the work.

Taking a shipped feature away spends the trust that built the project, so almost nobody does it. The path of least damage is to name a category of future features, usually the ones only larger organisations need, and charge for those. Dokploy says as much: if a feature is mainly useful to individual developers, it prefers to keep it free.

The trouble is timing. The features on the paid side, SSO, audit trails and high availability are exactly what a team running an Apache 2.0 PaaS needs after it has grown and after switching platforms has become expensive. A licence that is generous on day one and strict on day four hundred is not dishonest. It is a price you should be able to see before you commit.

This is a worked scenario, not a case study. Picture a six-person team running four servers on the free Dokploy core. A customer's security questionnaire arrives and asks for single sign-on. Dokploy's pricing page lists SSO and SAML under Enterprise, with custom pricing and a sales conversation.

Four servers on Startup would be $15 plus $4.50, so $19.50 a month, and still no SSO. The feature that triggered the question sits on the one plan with no number on it. The page does not say how these plans map onto the proprietary directories, so the honest step is to ask before you build a customer promise on it. Or you put an auth proxy in front and keep the open core as it is. Neither is a disaster. Both cost a week you had not planned for.

1. 1Read the LICENSE file, not the README badgeA badge can say Apache even when a repository carries extra terms. Open the file and look for anything added to the standard text.
2. 2Search the tree for a proprietary or enterprise directoryA folder named proprietary/, ee/ or enterprise/ is the licence boundary made visible. Note what is in it today.
3. 3Read the pricing page for the features you will need in a yearSSO, audit logs, backups to your own storage, high availability. Whichever tier they sit on is your future bill.
4. 4Ask what happens to a feature you rely onA written commitment, like the one quoted above, is worth more than silence. It is not a legal term, so weigh it as a promise.
5. 5Keep your exit boringStandard Dockerfiles, a plain Postgres dump you have tested, environment variables in one file. See our Docker hosting explained for what portable looks like.
6. 6Pin what you runRecord the release you deployed. If the next one changes terms, you decide when and whether to move.

We are a hosted platform, so we are not the answer to a question about which self-hosted panel to run. If you want the panel route, Coolify against Railway is the fairer comparison, and the best Docker hosting providers puts the panels next to managed options.

Our own repository is licensed Apache 2.0 today, though we sell a hosted service rather than asking you to run an Apache 2.0 PaaS yourself. Apply the same checks to us: a licence file is a snapshot, and a promise from a company is only as good as its record. We have a short one.