NocoDB's Enterprise Gate Is the Third Warning: How to Vet a Self-Hosted Platform's License Before It Vets You

If you self-hosted NocoDB to escape Airtable's per-seat meter and woke up to ERR_LICENSE_REQUIRED in July, you already know the pattern — you just haven't named it yet.

NocoDB's 2026.07.0 release on July 23 shipped two genuinely useful features — Calendar Sync (Google Calendar, Outlook, CalDAV) and Image Annotations (pin a comment to a spot on an image) — available only if you activate an Enterprise license key. The changelog table says it plainly: CE / Free: – | Paid / Enterprise: ✅. So did 2026.06.0 (NocoDB Sync, Document Version History: enterprise-only) and 2026.06.1 (Custom Sync, White-Label, SQL Server support: enterprise-only). The mechanism is elegant and easy to miss: there is no separate nocodb-ee image. nocodb/nocodb:latest ships both code paths; setting NC_LICENSE_KEY flips the gate. No fork, no build flag — just a key check at runtime.

This is the third time in eighteen months a beloved self-hosted tool has moved the line between "open" and "pay us" after a community already built on the assumption the line wouldn't move. Plex did it to remote streaming. MinIO did it to its admin console. NocoDB just did it to new features in a way that will keep doing it every release. The question isn't whether open-core vendors can gate features — they can. The question is how you, as the person who has to run a platform for your team, tell the difference before you commit between a permissive commitment that can't be quietly narrowed and an open-core commitment that can.

This post gives you the table, the receipts, and a five-question checklist you can run in ten minutes on any self-hosted PaaS that asks for your trust.

The pattern in one table: three tools, same move​

Every entry below was free or community-included, then gated behind a paid license while the project still called itself self-hostable. The details differ; the shape doesn't.

A few honest nuances, because the pattern matters more when you don't caricature it:

• NocoDB is still AGPL-3.0 for the base, not closed-source. You can still self-host the core. The shift is that new capabilities increasingly land on the paid side of the same binary. A discussion thread in 2026 noted the project now describes itself as Fair Code / Sustainable Use License — consult your own counsel on what that means for your use.
• Plex softened the landing: one Plex Pass on the server owner covers every friend you share with, and its mobile apps dropped the old $4.99 playback fee at the same time. If you host for family, one subscription solves it.
• MinIO's server is still AGPLv3 and buildable from source; what's gone from the free path is the operability layer and the convenience of docker pull. The community fork OpenMaxIO exists but has been dormant for months — which is itself a data point about fork viability.

The point of the table isn't that these vendors are villains. It's that "self-hosted" stopped answering the question "will next quarter's feature be in my build?"

How each gate actually works (so you can spot the next one)​

NocoDB: the same-image entitlement check​

NocoDB's docs are explicit: "Same image, license-gated. nocodb/nocodb:latest ships with both Community and Enterprise code. Enterprise features activate when a valid license key is set." That design is why the gate is silent until you hit it — docker pull succeeds, the app boots, and only when you call a gated API (e.g., feature_docs_apis on NocoDocs, SSO, row-level security, table/field-level permissions, audit logs) do you get a license error. Community issues like #14357 ("Documents API gated to Enterprise on self-hosted while Cloud gets it at Business") show the asymmetry can even differ between self-hosted and NocoDB Cloud tiers.

A CLA (Contributor License Agreement) is part of why this is structurally possible. As the project's own licensing discussion notes, every contributor signs a CLA with NocoDB, Inc., which lets the steward distribute the same codebase under two licenses — AGPL for the free path, commercial for the paid path — without needing every contributor's sign-off on each gated feature. That isn't malice; it's dual-licensing mechanics. But it means the steward can keep choosing the paid path for new features without ever changing the license header on your installed copy.

Plex: the entitlement check that followed you home​

Plex announced on March 19, 2025 that free remote streaming would end April 29, 2025, paired with a Plex Pass price increase and a new, cheaper Remote Watch Pass. Enforcement rolled out platform by platform — Roku first, then Android TV, Fire TV, Apple TV and game consoles through 2026. Community write-ups in 2026 noted smart TVs were among the last to enforce, which made the paywall easy to miss until your living-room app did.

The pricing ladder matters for self-hosters: Remote Watch Pass (~$1.99/mo) unlocks only remote playback for one viewer from any server shared to them; Plex Pass ($6.99/mo) unlocks remote for every user on a server you own, plus transcoding and premium features. Plex's own framing was that local-network playback stayed free — the gate is specifically "streaming your own files from outside your own house," which is the core use case that made people self-host Plex in the first place.

MinIO: the operability rug-pull​

MinIO's trajectory is the longest-running cautionary tale and the most expensive to unwind:

• 2019–2021: License moved Apache-2.0 → AGPLv3, with a discussion thread ("Sudden, Silent License change?" — 88 upvotes) marking community surprise and an enforcement posture that pushed commercial users toward a paid license.
• February 26, 2025: Co-founder Harshavardhana opened PR #3509, which replaced the full Admin Console with a stripped-down Object Browser. Management actions (user/policy management, external IdP) were removed from the community build.
• 2025–2026: Cloudian/blog and community forks documented that regaining the console required MinIO's paid AIStor product, quoted from $96,000/yr minimum (software + support) to $244k/yr per PB. In October 2025 MinIO stopped publishing community Docker images/binaries altogether — self-host now means building from source, and the repo went read-only shortly after.

MinIO's AGPLv3 core is still forkable, which is how OpenMaxIO came to exist as a console fork. That its activity stalled after a few months is a useful reminder: the right to fork is not the same as the capacity to maintain a fork.

The five-question vetting checklist (run this before you pick a PaaS)​

Use this on any self-hosted platform that asks you to build your workflow on it — NocoDB, Plex, MinIO, or the PaaS you run underneath them. Ten minutes, five questions, concrete artifacts.

1. What does the license file actually say, and who can change it without you?

Open the repo's LICENSE file, not the marketing site. Apache-2.0 is permissive: you can fork, modify, and run without sharing changes back, with an explicit patent grant. AGPL-3.0 is copyleft-for-network-services: run a modified version as a service and you must share the changes. Elastic-2.0 / SSPL / "Fair Code" / "Sustainable Use" are not OSI-approved open source — they restrict commercial use. Then check for a CLA or Contributor Assignment: if every contributor signs a CLA assigning rights to a single vendor, that vendor can relicense future contributions without consulting the community. DCO (Developer Certificate of Origin, a signed-off-by line) preserves distributed rights; a CLA centralizes them. A CLA isn't a red flag by itself, but it is the mechanism that makes same-image gating and license shifts possible without a fork.

2. Is there a single binary with a runtime key check, or a real community build?

Same image, license-gated plus NC_LICENSE_KEY is a tell: the gate isn't a build-time distinction you can fork around without patching entitlement checks throughout the codebase. A separate community edition (minio/minio vs minio/aistor, gitlab-ce vs gitlab-ee) at least makes the boundary auditable. Ask: can I build the fully-featured version from source without a key?

3. What's the pricing-page changelog over the last 12 months?

Plex's remote-streaming restriction, MinIO's gradual move from generous community → degraded community → no community images, and NocoDB's three consecutive enterprise-gated releases all showed up first as pricing or changelog deltas, not license-file commits. Pull the Wayback diffs. If every new marquee feature lands as CE: – | Enterprise: ✅, that's your roadmap.

4. What does "free" actually include for the workload you care about?

Not "is there a free tier" but "do the features my team already depends on stay in the tier I'm on?" MinIO kept the S3-compatible core free and gated the operability layer; NocoDB kept the spreadsheet UI free and gated sync/integrations/permissions; Plex kept local playback free and gated remote playback. Map your workflow — not the vendor's demo — onto the edition table.

5. If the vendor gated the next feature I need, could I credibly fork or stay on the current build?

Check three things: (a) is the last fully-open tag buildable from source without proprietary blobs, (b) does a community fork already exist with sustained commits (not a single readme commit), and (c) what's your own cost to pin and patch versus paying. MinIO's no-more-Docker-images moment made pinning without a build pipeline impossible; OpenMaxIO's dormancy answered (b).

If a project fails three of five — CLA-centralized rights, same-image gating, changelog drifting enterprise-ward, core-workflow features already gated, no viable fork — treat every future release as potentially enterprise-only and budget accordingly. That's not cynicism; it's what the last three cases did.

What an Apache-2.0 commitment without asterisks actually looks like​

There's a reason this list keeps returning to Hetzner-box economics and license mechanics together: cost and control are the same question when you self-host a PaaS. A platform that is Apache-2.0, no CLA relicensing, and no runtime entitlement gate gives you a property the open-core projects above structurally can't — the current build is also the complete build, and your fork right is also a practical right because you can build what you run.

Bex is a concrete example of that shape, not because it's the only one but because it makes the contrast explicit:

• License: Apache-2.0, OSI-approved, with the patent grant and without a "Sustainable Use" addendum. No per-editor key to unlock primitives.
• No same-image gate: The operator in lego/ reconciles App CRs in bex-system into running services; there is no NC_LICENSE_KEY-equivalent that gates deploy-from-git, custom domains + TLS, or suspend/resume. If it ships in the image, it runs.
• Buildability: git push → build → deploy is the product, not a tier. The build pipeline, the operator, and the Render-compatible API are in the same open tree you'd fork.
• Non-goals are stated, not implied: Managed databases, multi-cloud abstraction, and closed SaaS are explicit non-goals in docs/vision.md — which is itself a vetting signal (a project that tells you what it won't productize is less likely to quietly productize it behind a paywall).

You don't have to choose Bex for the checklist to be useful — run it on Coolify, Dokploy, CapRover, or any platform you already run. The point is to demand the same level of explicitness from whatever you bet your PaaS on that this post demanded from the three examples: what's the license, where's the gate, and what does the last six months of changelogs say about where the next gate will go?

What to do this week​

If you already self-host NocoDB, Plex, or MinIO, do three things before the next upgrade:

1. Pin your current working image by digest, not tag, and snapshot the feature table for the version you're on. latest on a same-image-gated project is how a docker pull becomes a paywall.
2. Grep your workflow for gated features. For NocoDB, search your usage for SSO, audit logs, field/table-level permissions, and any automation that calls docs/meta APIs. For Plex, check whether remote access is load-bearing for your household. For MinIO, check whether anyone still depends on the console for policy/IdP changes.
3. Run the five-question checklist on your PaaS layer itself — the platform that provisions the machines under those apps. The cheapest time to learn your PaaS has a runtime key gate is before you need to scale to a second machine.

Open-core isn't a slur — plenty of projects use it sustainably and transparently. But after Plex, then MinIO, then NocoDB's three enterprise-gated releases in a row, "self-hosted" alone no longer answers whether the next feature you need will be in your build. The license file, the CLA, the image architecture, and the changelog do. Read them before you git push.

Bex.co is the open-source, AI-native Render alternative — push a git repo, get a running HTTPS service on machines you own. Apache-2.0, no per-seat entitlement gate, Cluster API under the hood. Star the repo on GitHub or deploy your first app today.