File Browser: A Self-Hosted File Manager That Just Went Unmaintained

What File Browser Solves and Who It Was For

File Browser is a web-based file manager that you point at a single directory on a server. It lets you upload, delete, preview, and edit files through a browser interface. The README describes it as a create-your-own-cloud tool: install it, direct it to a path, and access your files. The intended audience is someone who wants a lightweight, self-hosted alternative to a full cloud storage service, without the overhead of Nextcloud or a dedicated NAS interface. It is written in Go, which means it compiles to a single binary and is easy to deploy on a small VPS or a home server. The project was archived on 2026-09-01, with the last planned release already shipped. That changes the answer to who it is for: it is now only for someone who accepts unmaintained software with known security issues, or who wants a codebase to fork.

How It Works: A Single Binary, a Specified Directory, and a Web UI

The core mechanism is simple. You run the File Browser binary and give it a path to a directory. It then serves a web interface that maps to that directory. The interface supports basic file operations: upload, delete, preview, and edit. The README does not detail the internal architecture, but the repository layout and documentation suggest a standard Go HTTP server with a frontend. The notable architectural point is that sessions are self-contained JWTs. The README explicitly states that sessions are not server-side identifiers, so they cannot be revoked. That means logout, password changes, and token renewal do not invalidate previously issued tokens. They remain valid until they expire. The same refresh token can be redeemed repeatedly. This is a fundamental design choice that has security implications, and it is one of the two known issue classes that the maintainers say will not be fixed.

Getting It Running: Commands and Configuration

The README points to the docs directory for installation and configuration details, but it does not include exact commands in the snippet provided. What is clear is that you run the binary and direct it to a directory. The README mentions a flag: `--disable-exec=false`. This flag controls the command runner feature. It is disabled by default, and the README strongly advises leaving it off. To run it safely, the documentation recommends putting it behind a reverse proxy that terminates TLS and performs its own authentication. It also recommends running it unprivileged, inside a container, with only the directory you intend to serve mounted into it. The exact command to start the server is not in the README, so you would need to check the docs or the release notes for the precise invocation. But the configuration surface is small: a path, an optional flag to enable command execution, and a reverse proxy in front.

The Command Runner: A Feature That Is a Liability

The command runner is a feature that lets you execute commands on the host through the web interface. The README is blunt about it: it is plagued with vulnerabilities across many published advisories, and it would need a full rewrite to be made safe. It is disabled by default, but if you re-enable it with `--disable-exec=false`, the README says to treat the ability to run commands as equivalent to shell access on the host. That is a severe warning. For any deployment, leaving this off is the only sensible choice. But the existence of this feature, and its history of vulnerabilities, is a reason to question whether the project was ever suitable for internet-facing use. Even with the runner disabled, the session handling issue remains. This is not a case of a minor bug; it is a structural weakness in two core areas.

Session and JWT Handling: A Fundamental Revocation Problem

The session handling is the second unaddressed issue class. Because sessions are JWTs, they cannot be revoked server-side. The README explains that logout, password changes, and renewal do not invalidate previously issued tokens. They stay valid until their expiry. The same refresh token can be redeemed repeatedly. This means a leaked token is valid until it expires, no matter what you do. For a file manager that might handle sensitive files, this is a serious limitation. Most web applications use server-side sessions that can be invalidated on logout. File Browser chose a stateless approach, which simplifies scaling but sacrifices control. The README advises assuming a leaked token is valid until expiry. That is a hard constraint to design around. If you need the ability to revoke access immediately, this is the wrong tool.

Maintenance and Upgrade Cost: Now Zero, and That Is the Problem

The project is archived as of 2026-09-01. The last planned release has shipped, and there will be no further releases, bug fixes, or security fixes. That means the maintenance cost is zero because there is no maintenance. But the upgrade cost is effectively infinite: you cannot upgrade to a fixed version because no fixed version will ever exist. The Apache-2.0 license allows you to fork the code and maintain it yourself, and the README notes that CONTRIBUTING.md remains useful for anyone forking it. But that is a significant undertaking. You would need to address the two known issue classes on your own, or accept them. For most users, the absence of security fixes is a dealbreaker. The project had a long history, with releases up to v2.63.23, but that history ended in July 2026. The background post is titled Goodbye File Browser, for Real This Time, which suggests this was not a sudden decision.

Alternatives: What to Use Instead

If you need a maintained file manager, look at alternatives. The README does not name any, so this is a general comparison. A common alternative is Nextcloud, which offers a full cloud platform with file sync, sharing, and apps. The difference in approach is that Nextcloud is a heavy PHP application with a database, while File Browser is a single Go binary with no external dependencies. Nextcloud gives you server-side sessions and active development, but it requires more resources and configuration. Another option is a simple SFTP server with a web client like SFTPGo, which also runs as a single binary and focuses on file transfer rather than a full UI. The key difference is that SFTPGo is actively maintained and has a different security model. For a minimal, unmaintained tool, you could also just use a plain web server with directory listing, but that lacks editing and uploading. The choice depends on whether you prioritize simplicity or ongoing security.

Who Should Adopt It: A Narrow Window

File Browser is not a tool to adopt fresh. It is a tool to consider only if you already run it and are willing to accept the risks, or if you want to fork it. The README's own guidance is to treat it as unmaintained software: do not expose it directly to the internet, keep the command runner disabled, and run it unprivileged in a container. If you follow that, it might still serve a niche use case on a trusted internal network, where the lack of revocation is tolerable because you control the clients. But for any new deployment, the absence of security fixes is a decisive negative. The project's own documentation tells you the two major issue classes will not be fixed. That is as clear a signal as you can get. If you need a file manager with a future, pick something else. If you need a quick way to manage files on a home server and you can isolate it, File Browser might work, but verify your version against the security advisories first and plan to replace it eventually.

Editorial conclusion

Adopt File Browser only for internal, low-risk file management on a trusted network, where you can keep it behind a reverse proxy with its own authentication and the command runner disabled. Do not use it if you need internet-facing access, session revocation, or ongoing security fixes. Before deployment, verify your exact version against the published security advisories and confirm you can live with the JWT token expiry window. If you need a maintained tool, look elsewhere; File Browser is now a snapshot, not a living project.

Official sources

1. Official README
2. Project repository
3. Release notes