Plex Paywalled Your Own Movies: Three Self-Hosting Rug-Pulls and the Apache 2.0 Test That Catches the Next One

For a decade, Plex's pitch to self-hosters was simple: run the server on your own hardware, stream your own media, pay nothing for remote access. Then in March 2025, Plex announced that after April 29, streaming your own files to your own TV outside your house would cost money — $1.99 a month for a new Remote Watch Pass, or $6.99 for a Plex Pass. Lifetime Plex Pass pricing jumped at the same time. By late 2025, the paywall hit Roku. In 2026 it rolled out to every smart-TV and console app.

Nothing about your server changed. The files are still on your disk. The network is still your network. What changed was the vendor's decision that a feature you already relied on now had a price tag — and that your viewing data could help pay for it on the advertising side too.

Plex is not an outlier. In the 18 months from early 2025 to mid-2026, three widely self-hosted tools each moved a previously free capability behind a paywall, and the community response converged on a single phrase: "self-hosting is being enshittified." A late-December 2025 post on troubled.engineer cataloging the pattern hit the top of Hacker News and crystallized a question every team picking self-hosted infrastructure now has to answer: what does "open source" actually guarantee about the next release?

Three rug-pulls, one pattern — and the license test that separates a promise from a marketing line — is the core of this post.

Three Features You Had, Then Didn't​

The fastest way to see the pattern is side by side. Each row is a feature that worked for free, then didn't — same binary, different license check at runtime.

The details matter because the mechanism is the same each time. None of these projects shipped a separate "enterprise binary." They shipped one artifact and resolved the feature set from a license key or account flag at runtime. The open-core creep was invisible until it wasn't — each individual step was defensible on its own, and the cumulative direction was never announced as a product decision.

MinIO's timeline is the most complete illustration. It didn't happen overnight. The project moved from Apache 2.0 to AGPLv3 in 2021, stripped the console in May 2025, stopped publishing community Docker images and binaries in October 2025, and had its repository archived as "no longer maintained" by early 2026. A community fork followed — but by then every team pinned to minio/minio had a migration to plan.

NocoDB's version is subtler. The July 2026 release notes don't say "we removed a feature." They say certain capabilities require an Enterprise license. The Documents API returns ERR_LICENSE_REQUIRED: The "feature_docs_apis" feature requires an Enterprise license on the same self-hosted image that served it before. The earlier audit-log move was merged under a pull request titled "fix(nc-gui): audit log ui changes" — a UI fix that was actually a feature removal. And the asymmetry runs both ways: on NocoDB Cloud, some of the same features are available below Enterprise, while self-hosted users hit the gate at a lower tier.

Plex's version adds the data dimension. Alongside the paywall, Plex's updated privacy policy expanded language around "sharing" and "sale" of data to third-party advertisers, and its ad-supported streaming and interactive ad platform (built with ACTV8me) became a larger part of the business. Plex says it does not sell information about your personal media library — but the policy does describe sharing watch history, reviews, and other service data with advertisers when account settings are public, and community reports of Plex/Roku/TVDMB API ecosystems leaking watch history to IP-based ad targeting have kept the question alive. The point is not whether Plex crossed a specific line. It is that remote streaming — the feature self-hosters valued — was paywalled at the same time viewing data became more central to how the company makes money.

Why "Self-Hosted" Alone Doesn't Answer the Trust Question​

The backlash posts all ask the same thing: "what's the point of self-hosting if the vendor can unilaterally take features away or harvest your data anyway?" The honest answer is that "self-hosted" describes where the bits run, not what the license guarantees about the next release.

There is a spectrum, and the labels matter:

• Apache 2.0 (or MIT) with no Contributor License Agreement (CLA) trap. You can use, modify, self-host, and fork without permission. If the vendor changes direction, the last Apache-2.0 commit remains forkable by anyone. No runtime license check can retroactively remove it.

• Open core. The core is open, but commercially interesting features live behind a proprietary gate. The binary may be one artifact with a license-key check. Each release can move the line — audit logs this quarter, an API version next quarter — without changing the license file at all.

• Source-available / Fair-Code / Sustainable Use. The source is visible, but self-hosting at scale, commercial use, or specific features require a paid license. NocoDB's 2026 shift to Fair Code is explicitly in this bucket: free to view and modify, but new capabilities resolve to Enterprise at runtime.

• AGPL / SSPL / Elastic License. Copyleft or non-compete licenses that restrict how you can offer the software as a service. Not the same as "paywalled features," but still a constraint teams need to model.

The rug-pull risk lives in the middle two. A project can stay "open source" in its marketing while every new feature ships behind a gate. The source for the gated feature may never be published under the open license at all — which is legal if every contributor signed a CLA giving the vendor sole right to relicense. The vendor can withhold the source of the extended version while the open version stays frozen.

That is why the Plex/MinIO/NocoDB pattern keeps recurring. "Self-hosted" told you where the server runs. It never told you who decides which features your next docker pull will actually include.

The Fork Test: What Survives a Rug-Pull and What Doesn't​

The counter-trend is just as real as the rug-pull. Every major paywall has produced a community-governed fork — and the fork's viability is itself a signal about the license.

Jellyfin over Plex. Jellyfin is the community fork of Emby (which itself closed its source), now fully GPL-2.0, with no paywall, no account requirement, and no ad platform. It is the default answer in every "Plex alternative" thread since the paywall. The trade-off is real: less polished clients, more self-assembly on transcoding and remote access. But no one can move Jellyfin's remote streaming behind a pass, because there is no vendor with that power.

Immich over Plex/Photos. Immich has become the default self-hosted photo stack (paired with Jellyfin for video) precisely because it is AGPL-adjacent community infrastructure with no enterprise gate. Its rise tracks the same trust migration.

Forgejo over Gitea. After Gitea's trademarks and operations were silently transferred to a for-profit corporation, Forgejo hard-forked Gitea in 2024 under community governance (Codeberg e.V., a nonprofit, holds the trademarks). Forgejo v14.0 shipped in January 2026 with its own Actions runner, CodeMirror editor, and federation work. Codeberg itself migrated to Forgejo. The lesson is governance, not just license text: a CLA or trademark held by one company can enable a rug-pull even before the license changes.

The MinIO fork. After the community edition was archived in early 2026, a FOSS community fork reclaimed the pre-stripped codebase. Projects like RAGFlow, ClickHouse's code-interpreter, and others have published migration guides off minio/minio to Garage, SeaweedFS, or the fork. The fork exists because the last Apache-2.0-era (and later AGPL-era) code was available to fork. But "available to fork" is not the same as "zero migration cost" — every team that built automation around the admin console or the official image still paid the migration tax.

The fork test is simple: if the vendor disappeared tomorrow, could the community ship the next release from the last open commit? For Apache-2.0 without a CLA bottleneck, the answer is yes, and the fork can be commercially usable. For open core with a CLA, the answer is "yes, but without the gated features" — which is exactly why the gate keeps moving. For AGPL/SSPL projects, the answer depends on whether the community wants copyleft.

How to Vet a Platform's License Commitment Before You Bet Your Fleet On It​

If you are choosing infrastructure that will run tenant workloads — a PaaS, a storage layer, a database, a media or automation stack — the vetting checklist is concrete. Run it before you pin the image, not after the paywall lands.

1. Read the license file, then read the CLA.

• Is the license Apache 2.0 or MIT with no "enterprise edition" asterisk?
• Does the project require a Contributor License Agreement that assigns relicensing rights to a single company? If yes, that company can legally withhold the next feature from the open version even if your contribution is in it.
• Is there a LICENSE file plus a separate ENTERPRISE_LICENSE or COMMERCIAL_FEATURES.md that lists gated capabilities? That is open core documented honestly — treat it as such.

2. Check whether the binary gates features at runtime.

• Pull the image and search for ERR_LICENSE_REQUIRED, license_key, or feature_flag in the codebase. NocoDB's pattern — same image, feature resolved from a key — is the modern open-core tell.
• If the feature set depends on a key, every future release can narrow the free set without a version bump you would notice in a changelog.

3. Confirm the fork path is real, not theoretical.

• Is there a recent community fork with active releases and a governance body that is not the vendor? (Forgejo/Codeberg, Jellyfin, the MinIO community fork.)
• Does the fork have its own trademark and domain held by a nonprofit or foundation? Trademarks decide who gets to call the fork "the project" in search results.

4. Measure governance, not just license text.

• Who merges pull requests? A single vendor employee or a multi-org committee?
• Are security advisories, roadmaps, and release notes published outside the vendor's marketing site?
• Did the project ever change its license without a community vote? (MinIO's 2021 Apache-2.0-to-AGPL move is the canonical warning.)

5. Model the migration cost of the gated feature.

• If audit logs, an admin UI, or a specific API version moved to Enterprise tomorrow, what breaks? Would you need to rewrite automation, retrain operators, or migrate data?
• Prefer platforms where the operational surface (provisioning, machine lifecycle, backups) is declarative and provider-agnostic. A Cluster API fleet on owned Hetzner hardware, for example, doesn't have an "admin console" that a vendor can strip — the console is Kubernetes itself.

A platform that passes this checklist is not promising it will never charge for anything. It is promising that the thing you already depend on won't be taken away next quarter, and that if it tries, you have a real, commercially usable fork to move to without rebuilding from scratch.

What "Apache 2.0, No Asterisk" Actually Has to Mean​

The phrase is easy to say and easy to dilute. For a self-hosted PaaS asking tenants to trust it with their infrastructure, it has to mean all of these at once:

• The entire platform — not just the core — is Apache 2.0. No "community edition" with a smaller feature set.
• No CLA that lets a single company relicense contributions into a proprietary edition.
• No runtime license key that resolves the feature set. The binary you pulled is the feature set.
• Trademarks and domains held in a way that a community fork can credibly continue if the vendor changes direction.

Anything less is open core with better copy. The Plex, MinIO, and NocoDB episodes didn't happen because self-hosting failed. They happened because "self-hosted" was never the guarantee — the license and the governance were, and the gap between the two was where the paywall went up.

Teams that lived through one of these migrations don't need convincing. Teams choosing their next platform can still avoid it — by vetting the license the way they vet the uptime, before the next release notes quietly move the line.

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, no open-core asterisk, no enterprise gate on features you already depend on. Star the repo on GitHub or deploy your first app today.