File Browser is archived and will receive no more security fixes

September 1, 2026. The filebrowser/filebrowser repository went read-only, and File Browser — one of the most widely installed self-hosted web file managers, with 36,000 stars and 4,100 forks on GitHub — will never receive another security fix. On July 27, 2026, v2.63.23, its last planned release, shipped; the next day, maintainer Henrique Dias announced the end. Why it matters: a web-facing file manager is a prime target, and there will be nobody left to patch the next flaw.

A pillar of homelabs and NAS boxes

File Browser is a single Go binary that exposes a full web UI for file management: upload, download, rename, link sharing, multi-user accounts, and per-folder permissions. Its simplicity — one executable, one config file, no runtime dependency — made it the default pick for homelabs, home-built NAS devices, and application images that need an embedded file view. That ubiquity is exactly what makes its archiving notable: many installs do not even know they depend on it.

This is not a recent fork or a niche competitor. It has been the reference in its category for years, maintained almost single-handedly by Henrique Dias, and distributed for a couple of dozen targets — Linux, macOS, Windows, FreeBSD, ARM — plus an official Docker image. Its repository shows more than 36,000 stars, which places the project among the most-followed self-hosted tools on GitHub.

The timeline: announced in July, archived in September

The end was gradual and announced. On July 27, 2026, Henrique Dias published v2.63.23, explicitly labeling it the last planned release. On July 28, 2026, he posted a blog entry titled “Goodbye File Browser, For Real This Time” — a definitive farewell after years of near-single-maintainer upkeep. On August 31, 2026, the GitHub organization was marked as archived; on September 1, 2026, the repository went read-only.

The timeline matters because it left a one-month gap between the announcement and the actual archive. Teams that saw the announcement in July had time to act; those discovering the archive today have no window left — the situation is already frozen.

What “archived” actually means

“Archived” is a misleading word, because it does not convey the complete stop it denotes here. Concretely:

• No more releases, no more bug fixes, no more security fixes. v2.63.23 is the endpoint.
• Existing releases and Docker images stay online and will not be withdrawn. Everything keeps working — which is both the good news and the problem.
• The code remains downloadable and forkable, but the central project is dead.

The nuance that should drive your decision is the second one: your instance will not stop working; it will age without a net. The day an exploitable flaw — path traversal, an authentication bypass, an injection — is published against File Browser, there will be no official patch and no security advisory. You will be on your own.

The real risk: an exposed surface that will never be patched again

A file manager is, by nature, a first-class attack surface. It handles uploads, file paths, permissions, and accounts, and it is very often exposed behind a reverse proxy to allow remote access. The class of vulnerabilities that has historically affected it — directory traversal, symlink sandbox escape, code execution — will not vanish with the archive; on the contrary, it will stay open forever from the next discovery onward.

The worst case is not theoretical. An internet-facing File Browser instance, with no fixes to come, becomes a persistent backdoor the day a CVE lands: the attacker knows the target will never be patched, which extends the exploitation window indefinitely. That is precisely the profile botnets and ransomware operators look for in their automated scans.

Migrating: the maintained alternatives

The least painful migration path is Filebrowser Quantum, a fork that keeps compatibility with File Browser’s database format while patching known vulnerabilities — in other words, a near-transparent transition for anyone who wants to keep the same interface and configuration model. For teams ready to switch tools, the commonly cited alternatives include copyparty, FileRise, and Filestash, three active, maintained web file managers; SFTPGo covers the same need at the protocol level if the web UI is only a bonus.

Whatever the target, migration is not just swapping a binary. The real work is the inventory: find every running instance, every image that embeds it, every reverse proxy that exposes it, then pin the current version while you plan. A forgotten instance behind a subdomain is an instance that stays vulnerable.

A migration in three steps

The concrete path breaks down into three stages. First, the inventory: list your containers and compose files to find everything that embeds File Browser. One command covers most cases:

# Find running File Browser containers on a host
docker ps --format '{{.Image}} {{.Names}}' | grep -i filebrowser

Then, the choice: Filebrowser Quantum to stay on the same interface and database, or a maintained alternative — SFTPGo, copyparty, Filestash — if you are ready to switch tools. Finally, the cutover: run the new instance in parallel on the same volume, validate the permissions, then tear down the old container. Keep the old instance’s config file on hand during the parallel run — it is the reference for recreating your users and permission rules in the new tool.

The last step is the one most often skipped: remove the old image from the fleet. An archived image lingering in an unused docker-compose.yml remains a potential entry point — and nobody will remember to patch it, because there is no patch left.

The deeper lesson is dependency awareness. File Browser is not only run directly; it is embedded in many other self-hosted images and NAS appliances. When you audit your stack, look beyond the containers literally named filebrowser — check the documentation of your other services for whether they bundle it, and record its archive date wherever you track maintenance. A project that stops shipping fixes is a fact you want written down, not rediscovered during an incident.

Verdict

If you expose File Browser to the internet, even behind authentication, migrate without delay: there will be no more fixes, and each extra day raises the odds that a public flaw finds you before your migration does. If the instance is strictly LAN-only, with no exposure and no remote-access account, the urgency is lower — but plan anyway: the end of fixes means you will carry sole responsibility for the next flaw, including an internal one. If you are starting a new project, do not build on an archived repository: pick a maintained fork like Filebrowser Quantum or an active alternative from the start.

The decision comes down to timing and exposure. An archived tool can still serve for years on a trusted network; exposed, it becomes a liability that degrades every day. The signal to take from File Browser is not that a tool dies — it is that, in self-hosting, project maintenance is a security property in its own right, on the same footing as the code itself.

References

• GitHub — filebrowser/filebrowser, repository archived August 31, 2026
• GitHub — filebrowser/filebrowser v2.63.23, last planned release, July 27, 2026
• Henrique Dias — “Goodbye File Browser, For Real This Time”, July 28, 2026
• Smart Stacking — File Browser is Being Archived: Top Alternatives & Migration Guide, July 28, 2026