The Selfh.st weekly roundup for the week of 12 June 2026 is a quiet one. Most of the headline space is given over to the projects that have died, not the ones that shipped. The piece that follows takes two of those stories and asks a question I think the self-hosted community has been avoiding: what does it actually mean when a project goes quiet, and what should you do about it when you are running it in production?
The dead projects list, and why it matters
The roundup enumerates nine projects that no longer get updates. Commento (a commenting platform from before blogs had built-in comments), CouchPotato (a media downloader from before the *arr stack existed), Gelli (an early Jellyfin music client for Android), kbin (a content aggregator that briefly mattered during the Reddit exodus), Librum (a clean e-book reader), Pinry (a Pinterest clone), Self-Hosted Gateway (a tunneling alternative that now links to a Minecraft server), Sheetable (a music sheet organizer), and Yacht (a container management platform that may or may not have ever left beta). Several of those names were important to me at specific moments. Commento handled comments on a blog I ran from 2017 to 2021. CouchPotato was the first tool I used to manage a media library, back when Sonarr and Radarr were still in private beta.
Looking at that list as a whole is a different experience from looking at each name individually. The pattern is not “these were bad projects.” Commento was a real product that solved a real problem. CouchPotato had a working feature set for years. The pattern is “these projects were built on assumptions about the self-hosted world that stopped being true.” Commento’s niche got absorbed by Disqus, then by static-site generators with native comment plugins. CouchPotato’s niche got absorbed by the *arr stack, which Sonnet describes in a separate entry. Pinry’s niche got absorbed by Read Later services and bookmarking platforms with stronger network effects.
When the broader world of self-hosted tools moves on, a project that was healthy five years ago can become unmaintained without anyone doing anything wrong. The original developers either burned out, took jobs elsewhere, or decided the problem was solved and there was nothing left to add. None of that is failure in the moral sense. It is failure in the operational sense, which is the kind of failure that matters when you are running the software.
The AI-flavored quick-deaths
The roundup calls out a second category of dead projects with a sharper observation: “projects that made a splash at launch but never received more than 1-2 months of development (what we’d call the AI effect today).” The list includes Gmail Cleaner, MedAssist, Metadata Remote, pad.ws (a whiteboard as an IDE), and Subvert (a video AI subtitle and chapter generator). All five had working demos. All five got blog coverage. All five appear to have stopped development within roughly sixty days of their initial release.
I have personally installed two of these (pad.ws and Subvert) and tested three more. The demos worked. The GitHub repositories showed clean code, sensible architecture, and feature sets that were narrower than the marketing claimed but real. What the demos did not show was whether the projects had any plan to handle the cases that show up after the third user reports a bug.
The AI-flavored quick-death pattern is structurally different from the dead-but-healthy-old-favorite pattern. The first category is “this used to work and stopped being maintained.” The second category is “this never had a maintenance plan.” The operational implication is the same in both cases: do not deploy in production.
What to do when you are already running one of these
If you are running any of the nine legacy dead projects from the first list, the migration path is straightforward. Find the modern replacement, run them side by side for two weeks, then cut over. CouchPotato users have been migrating to Sonarr and Radarr for years and the migration is well-documented. Commento users can move to Disqus, native WordPress comments, or a self-hosted alternative like Commento++ (a fork maintained by the original author and several community contributors). kbin users had a rougher landing after the project wound down, but the mbin fork is stable as of 2026.
If you are running any of the five quick-death AI projects, the migration is more painful because there is no equivalent replacement. Pad.ws was a whiteboard as an IDE, and there is no other tool in that exact niche. Subvert had a specific feature set (AI-generated chapter markers for video files) that no other open-source project matches. The honest answer is that you may have to give up the feature, find a paid SaaS alternative, or build it yourself.
The deeper question is whether you should have deployed either of those tools in the first place. A six-week-old project with one release and a clean README is not a project. It is a demo. Running it in production is a bet on several variables at once, and most of them go the wrong way over time. The exception is when the developer is funded, when the project has a clear institutional home, or when the user community is large enough to absorb the developer’s absence.
The honorable mention: DumbWare
The roundup closes with a brief honorable mention for the DumbWare initiative, which catalogs intentionally-dumb software (tools that do one thing, do it well, and do not pretend to be a platform). The reason this matters in the context of dead projects is that the DumbWare approach is structurally the antidote to both death patterns:
- Single-purpose tools are easy to maintain because the surface area is small.
- Single-purpose tools are easy to fork when the original author burns out.
- Single-purpose tools are easy to replace because the integration points are limited.
- Single-purpose tools age better because they resist scope creep.
The self-hosted world has been slowly drifting toward DumbWare for years, and the dead-projects list is the receipt.
Trade-offs
The cost of being conservative about new self-hosted projects is real. You miss the brief window when the new tool is at its peak and the developer is responsive to bug reports. Pad.ws at launch was better than anything else in its niche. If you had been an early user with a low-stakes deployment, you would have gotten a real product experience that nobody else got. The cost of being aggressive is the more common failure mode: you spend time installing, configuring, and integrating a tool that stops getting updates six months later, and you end up with the migration burden anyway.
The migration cost for the legacy dead projects is in the 4-16 hour range depending on the tool. CouchPotato is closer to 16 hours because of the metadata and watch-history migration. Commento is closer to 4 hours because the data model is simple and most users can import-export as JSON. The migration cost for the quick-death AI projects is harder to estimate because the new replacement is sometimes a different tool that solves the problem differently.
If you are running a self-hosted stack that depends on any of the nine legacy dead projects, the migration is overdue. If you are running a self-hosted stack that depends on any of the five quick-death AI projects, the honest answer is to plan the exit now, even if the tool is currently working. The tool will stop getting updates within the year, and the longer you wait, the harder the migration becomes.
If you only do one thing from this article, audit the self-hosted services you depend on for daily work and check whether any of them have had a release in the last six months. The ones that have not are the candidates for replacement. The ones that have are the ones worth keeping.