When the app you self-host gets archived: File Browser and your homelab's bus factor
File Browser is a lovely little thing: a single Go binary that gives you a clean web UI over a directory, beloved in homelabs, sitting on something like 35,000 GitHub stars. On 28 July 2026 its maintainer announced he's archiving it. The repo goes read-only on 1 September, no more releases, no more security fixes. I don't run File Browser, but the announcement is worth every self-hoster's attention, because it's the clearest recent illustration of a cost we all quietly signed up for: when you self-host it, you inherit its bus factor.
What actually happened (told fairly)
The announcement is on Henrique Dias's own blog, titled "Goodbye File Browser, for Real This Time," and the reason matters because it's not the one you'd assume. This isn't overwork burnout. In his words, "the will isn't there anymore... maintaining a codebase I don't think is good doesn't give me any pleasure," and, bluntly, "this can't be patched into shape. File Browser would need to be rewritten from the ground up, with security and a good API in mind."
The history underneath is the real story. Dias first tried to hand the project off to the community back in 2020, hence "for real this time." Maintainers came and went. By late 2025 it had drifted into being effectively unmaintained for about a year, so he took the reins back, and then decided archiving it honestly was better than pretending to carry something he no longer believed in. That's not a burnout story. It's a succession story, and the succession quietly failed. Existing installs keep working; the software just stops being maintained.
Stars measure popularity, not resilience
Thirty-five thousand stars is a lot of confidence to place in what turned out to be a fragile, one-person continuity chain. And that's the trap in the whole "just self-host it" ethos I otherwise love. The pitch is independence: no vendor can take it away from you. The flip side, which the pitch never mentions, is that no vendor is staffing it either. A GitHub star is a bookmark of approval. It says nothing about whether anyone will be there to ship a security fix the week a CVE lands.
You didn't choose it because a company stood behind it. That was the point. The bill for that freedom arrives the day the volunteer stops, and it's addressed to you.
This is the same lesson the Jellyfin leadership departures taught a few weeks back, from the other direction: there it was a governance wobble in a project that's continuing; here it's a project stopping outright. Same underlying risk, which is that volunteer open source is held up by a small number of specific humans, and humans get tired, change jobs, or simply stop believing in the code.
A bus-factor checklist before you add anything
I'm not suggesting paranoia, or paying for everything. I'm suggesting you price the risk before you build on it. Before I add a self-hosted app to my one box now, I ask:
- Bus factor greater than one? More than one active committer in the last six to twelve months, or is it a single account carrying the whole thing?
- Who owns it? An org with a documented handoff plan, or one person's personal repo? File Browser's handoff chain broke silently, and you'd only have noticed by watching the commit graph go quiet.
- Recency. Commit cadence and last release versus the pile of open, unanswered security issues.
- Exit ramp. Are my data and config portable, and is there already a credible fork or alternative before I need one?
- Blast radius. How many things on my box depend on this, and what breaks the day upstream goes read-only?
On the fork, carefully
There is an actively-maintained fork, FileBrowser Quantum, which has added the auth and security features the original lacked and dropped its old shell-command feature. If you're on File Browser, it's the obvious place to look. But note, fairly: Dias did not endorse it or any successor. He explicitly declined to recommend an alternative and pointed people at the usual self-hosted forums instead. So it's "a fork that exists and looks healthy," not "the blessed continuation." Which, honestly, is its own small lesson in evaluating the bus factor of the replacement, too.
None of this is a reason to stop self-hosting. It's a reason to do it with your eyes open: the software is free, and the maintenance is somebody's unpaid evenings. Say thanks, keep a backup and an exit plan, and don't be surprised when a volunteer decides they're done.