I read the Self-Host Weekly digest for the week of 22 May 2026 the morning after it landed, and two stories have been sitting in my head since. The first is Plex tripling its lifetime pass to $750. The second is GitHub confirming a breach of 3,800 internal repositories through a malicious VS Code extension. Both stories were framed in the digest as separate items, but they share a thread. They are both cases of a vendor trying to recover money or momentum from a self-hosting community that has stopped trusting them, and the community’s reaction in both cases will probably be the same: more of us move.
The digest itself covers more than those two stories. There is Proxmox PVE 9.2 with its dynamic load balancer. There is a 20GB archive of commercials from 2000 to 2015 that somebody built specifically to troll Plex users. There is the Komodo container management survey, and a resurrected r/MPD subreddit, and the Bitwarden “Always Free” line quietly disappearing from the pricing page. The full list is at the bottom of this post.
I am going to focus on the two stories that I think will actually matter three months from now.
The Plex lifetime pass change is not about the price
Plex announced that starting 1 July 2026, the lifetime pass price goes from roughly $250 to $750. The Self-Host Weekly writer pointed out that this is almost certainly a way to retire the lifetime plan without formally retiring it. Lifetime plans that look expensive discourage new buyers, and the people who bought at the old price get to feel good about having locked in. Plex gets a temporary cash bump from people rushing in before July 1st, then the plan effectively dies.
The reason this matters for self-hosters is not the $750. Most of the readers of this site already pay for a real Plex Pass for the mobile apps, or already use Jellyfin, and they were not going to buy a Plex lifetime pass anyway. What matters is that Plex is signaling that the free tier is on borrowed time. The mobile app and the hardware-accelerated transcoding (the feature that lets your server convert video on the fly for weaker clients) are the two things that keep people on Plex instead of Jellyfin, and both have been paywalled behind the Pass for years. If Plex’s next move is to start paywalling features that the free tier currently has, the migration to Jellyfin will accelerate.
The digest’s joke that “Jellyfin is quadrupling its price to $0” is real. Jellyfin is free, and it has no plans to stop being free. The Plex move is not going to drive a mass migration overnight. It is going to drive a slow one, mostly among people whose Plex setup is older than their kids.
The GitHub VS Code extension breach is the security story of the week
GitHub confirmed that roughly 3,800 internal repositories were accessed after an employee installed a malicious VS Code extension. The story is being reported by BleepingComputer, and the digest has the link.
The detail that matters is that the breach was not a 0-day in GitHub itself. It was a malicious extension in the VS Code marketplace that an employee installed, and the extension had access to whatever that employee’s GitHub authentication token had access to. In this case, the access scope (the set of repositories a single token can read or write) was wide, and the repositories in scope included internal source code across multiple business units.
Two things follow from this. The first is that VS Code extension permissions are not what most people think they are. Extensions in the marketplace run in the same process as the editor and can read any file the editor can read, including the contents of every open tab and every file the editor has permission to access. The VS Code extension security model is more like the Chrome extension model than the npm package model. Most developers treat extensions as if they were libraries, with the same trust assumptions, and that is the wrong mental model.
The second is that this is not going to be the last breach of this shape. Every developer tools company that has internal source code on GitHub or GitLab, and that lets its engineers install extensions from a marketplace, has the same exposure. GitHub was the company that confirmed a breach because GitHub is the company that the security press watches. The same thing is happening at smaller companies right now and will not make the news.
What I am doing about it
I am not uninstalling VS Code. The set of available extensions is too useful to give up, and the alternatives are not meaningfully better in this respect. Cursor and Windsurf have the same marketplace model. JetBrains has a similar extension model. The only way to actually reduce this exposure is to run extensions in a separate sandbox (a restricted environment that limits what code can do, even if the code itself is malicious) or to vet each one before installation, and neither of those is realistic for a working developer.
What I am doing is shrinking the scope. My GitHub personal access token now has read-only access to a smaller set of repositories than it did last week. My employer’s SSO (single sign-on, the system that logs you into every internal tool with one credential) session for GitHub times out after eight hours instead of staying logged in indefinitely. I have moved the handful of personal projects that were in my work GitHub org to my personal account, because I do not want a personal token to be the path to a work breach.
None of this is sophisticated. Most of it is the standard guidance that every security team sends out after a breach and that most developers ignore. The reason I am doing it now is that this breach was close enough to the workflow I actually use that the lesson landed. The breach was through an extension, and I use extensions. The breach was through a token with too much scope, and my token had too much scope. That is a closer match than the usual “breach at a company you have never heard of” pattern.
What I am not doing
I am not migrating off GitHub. GitHub is the largest host of source code in the world, and the alternatives are either smaller (Codeberg, Gitea.com) or self-hosted (Gitea, Forgejo, SourceHut). For open source work, GitHub is still where most contributors are, and the network effect (the fact that everyone else is on the same platform, which makes it the default place to discover and contribute to projects) is real.
For my own projects, I have started mirroring the public repos to Codeberg. The mirror is automatic, runs once a day, and pushes only when there is new content. If GitHub has another outage or another breach and I want to point people at a working URL for one of my projects, the Codeberg mirror is there. The mirror is read-only on Codeberg, so it does not accept pull requests (proposed code changes from outside contributors), but for a personal project that does not need outside contributors, that is fine.
This is not the same as “moving off GitHub.” It is a backup. But it is the kind of backup that most developers did not have until they needed one.
Trade-offs
Plex analysis is not free in confidence. I do not have visibility into Plex’s revenue or user data, and the $750 lifetime pass price could be a real valuation rather than a stealth retirement. If Plex is genuinely worth $750 to a long-term user, my read is wrong, and the lifetime plan continues to exist for years. The probability I would put on that is low, but not zero.
GitHub security changes come with a real cost. Rotating personal access tokens more often means more authentication friction (extra logins or re-authorizations that interrupt the workflow), and rotating SSO sessions more aggressively means I get logged out of internal tools at inconvenient times. For a developer who works across many repositories, the convenience of long-lived tokens is real, and giving it up costs something. The trade is worth it for me because I work on code that other people depend on, and the cost of a breach on my account is not just my own time.
Codeberg mirror setup took about an hour the first time. It is a git push to a remote with a cron job to trigger it daily. The cost is small. The benefit is also small in normal weeks and large in the bad week when GitHub is down or compromised.
Anyone running their own GitHub Actions workflows, or whose CI (continuous integration, the system that runs tests on every code change) deploys from GitHub, should consider what happens during a GitHub outage. The mirror is not a full substitute for Actions, but it is a substitute for “I cannot reach my own code.”
Bottom line
Two unrelated stories from the same week of the Self-Host Weekly digest point at the same trend. Vendors are making moves that erode the trust of self-hosting communities, and the communities are responding by building more redundancy. Plex is pricing out the lifetime tier, and a meaningful chunk of users will move to Jellyfin over the next year. GitHub had a breach through a third-party extension, and a meaningful chunk of developers will rotate their tokens more aggressively and mirror their public repos elsewhere. Both moves are cheap, both are partial, and both are the sensible default for the moment.
If I could send a message back to the version of me that had not yet rotated my GitHub tokens, I would say four things.
- Shrink the scope of every personal access token you have. Read-only is enough for almost everything, and a shorter expiration is better than a longer one.
- Mirror your public repos somewhere that is not GitHub. It takes an hour, and you will be glad you did it the next time GitHub has an incident.
- VS Code extensions are not libraries. Treat each one as if it ran with your user permissions, because it does.
- Rotate your SSO session before it auto-rotates for you. An eight-hour timeout is more annoying than a 24-hour one until the day it is not.