File Browser: a web file manager that is now archived

What File Browser does, and who it was built for

File Browser provides a file managing interface within a specified directory, and the README lists the operations plainly: upload, delete, preview and edit your files. That is the whole product. You install it on a server, point it at a path, and reach that path through a browser instead of SSH or SFTP. The README calls this a create-your-own-cloud kind of software, which is a fair description of the audience: people who want a web view of files they already own, on hardware they already control, without a sync client and without a hosted account.

The design assumes one bounded directory rather than a whole filesystem. That constraint shapes everything downstream, including the Docker image, which mounts /srv, /config and /database as volumes and runs as a non-root user. If you want a general-purpose NAS UI with shares, quotas and multi-protocol access, this is a narrower tool than that. It is closer to a lightweight front end for one folder.

The audience that should read carefully is anyone arriving now. The README opens with a warning that File Browser was archived on 2026-09-01, that the last planned release has already shipped, and that there will be no further releases, bug fixes, or security fixes. The last push to the repository was on 2026-07-27, and the most recent release listed is v2.63.23 on the same date. That is the state of the project: feature-complete by declaration, then closed.

How the command and the served directory fit together

The repository layout separates concerns more cleanly than a single-binary web app usually does. There are top-level packages for auth, files, fileutils, http, rules, runner, search, settings, share, storage, users and version, plus a frontend directory. The Go module is github.com/filebrowser/filebrowser/v2 and requires Go 1.25.0. Storage is backed by bbolt (go.etcd.io/bbolt) and asdine/storm, with an optional Redis path through github.com/redis/go-redis/v9. HTTP routing uses gorilla/mux, and sessions are built on golang-jwt/jwt/v5.

That last dependency is the one that matters most. The README states that sessions are self-contained JWTs rather than server-side identifiers, so they cannot be revoked. The practical consequence is spelled out in the same paragraph: logout, password changes, and renewal leave previously issued tokens valid until they expire, and the same refresh token can be redeemed repeatedly. A leaked token is valid until expiry. This is not a configuration mistake you can fix with a flag. It is how the session layer was built, and the README says it will not be fixed.

The runner and rules packages implement the command execution feature, which the README describes as plagued with vulnerabilities across many published advisories and in need of a full rewrite to be made safe. It is disabled by default. The README is explicit about what re-enabling it means: treat the ability to run commands as equivalent to shell access on the host. The compose.yaml in the repository does not enable it, and neither should you.

Installing File Browser with Docker Compose

The repository ships a compose.yaml, and it is the shortest path to a running instance. It defines a filebrowser service on image filebrowser/filebrowser:latest, publishing port 8000 on the host to port 80 in the container, with a named volume mounted at /flux/vault. A second service runs Redis with an ACL file so the default user authenticates with the password filebrowser.

services:
  filebrowser:
    container_name: filebrowser
    image: filebrowser/filebrowser:latest
    networks:
      - filebrowser
    ports:
      - 8000:80
    volumes:
      - filebrowser:/flux/vault
    environment:
      - FB_REDIS_CACHE_URL=redis://default:filebrowser@redis:6379

Start it with the usual Compose command from the directory containing that file.

docker compose up -d

After that, the service listens on http://localhost:8000. The README does not document the default credentials in the excerpt available here, so check the docs directory in the repository before exposing anything; do not guess a username and password combination. The image itself is built on busybox:1.37.0-musl, creates a user with UID and GID 1000, declares /srv, /config and /database as volumes, exposes port 80, and runs tini as the entrypoint. A healthcheck script runs every 5 seconds after a 2 second start period, so docker compose ps will show a health state rather than just a running state.

If you are not using Compose, the README points to the docs directory for install, configure and build instructions rather than reproducing them inline. The Dockerfile and Dockerfile.s6 at the repository root are the build recipes for the images.

The session model is the limitation that should decide adoption

Most file managers fail in ways you can patch around. This one fails in a way that is structural. Because sessions are self-contained JWTs, there is no server-side session table to delete from. When a user logs out, the token in their browser is discarded by the client, but the token itself remains valid until it expires. If an attacker copied it earlier, logging out does nothing. Changing the password does not invalidate it either, and the README notes the same refresh token can be redeemed more than once.

The README's own mitigation list follows from this. Do not expose File Browser directly to the internet. Put it behind a reverse proxy that terminates TLS and performs its own authentication. Run it unprivileged, inside a container, with only the directory you intend to serve mounted into it. Keep the command runner disabled. Those four instructions are the deployment model, not optional hardening. If your use case requires that revoking a session actually revokes access, File Browser is the wrong tool, and no amount of proxy configuration changes that.

The second limitation is the runner. It is off by default, which is the right default, but the README says the feature would need a full rewrite to be made safe and that it will not get one. Anyone who turned it on for convenience, for example to run archive or conversion commands from the web UI, is running something the maintainers describe as equivalent to shell access on the host.

File Browser alternatives and where the difference shows

The closest comparison in the search data is File Browser Quantum, which people search for both on its own and against this project, including a docker compose query. The distinction that matters for a decision is not feature lists but maintenance posture. This repository is archived, with the README stating there will be no further releases, bug fixes, or security fixes. A fork or a successor that is still receiving commits is a different risk category, and the two known issue classes documented here (command execution, and session and JWT handling) are exactly the kind of problems that only a maintained codebase can address.

For the file-serving job itself, the alternative approach is to skip the application layer. A static file server plus your existing authentication already covers read access, and SSH or SFTP covers write access, with session revocation handled by the operating system or the proxy rather than by a token you cannot cancel. What you lose is the browser UI: previews, in-browser editing, share links and the search package. Whether that trade is worth it depends entirely on whether you need those features or just a directory listing.

The repository also contains branding, transifex.yml and a frontend directory, which tells you the project was built as a product with translations and a designed interface, not as a thin directory index. That is the part you are giving up by moving to a plain file server, and it is also the part that will not receive fixes.

Licence, forks, and what upgrading looks like now

File Browser is Apache License 2.0, copyright File Browser Contributors. For anyone considering a fork, that is a permissive licence with an explicit patent grant and no copyleft obligation on your own code, which is why the README can point contributors at CONTRIBUTING.md and note that it remains useful to anyone forking it. This is a description of the licence terms, not legal advice; if you plan to redistribute a modified build, read the LICENSE file and get your own counsel.

The upgrade question is simpler than usual because there is nothing to upgrade to. The last planned release has already shipped, and the newest release listed is v2.63.23 from 2026-07-27. Pinning that tag and treating it as final is more honest than tracking latest, since latest will not move. If you build from source, the toolchain is Go 1.25.0 per go.mod, and the repository includes a Taskfile.yml, a .goreleaser.yml and a .golangci.yml, so a fork inherits a working build and lint setup rather than a blank slate.

The cost that does not go away is security review. Any advisory published against this code after 2026-09-01 has no upstream fix, so a fork carries the full burden of triaging the two documented issue classes plus anything new. That is a real ongoing cost, and it is the main reason to prefer an actively maintained alternative unless you have a specific reason to keep this one.

Running it anyway: the minimum safe configuration

If File Browser already serves a directory you care about, the README gives a concrete checklist rather than a vague warning. Keep it behind a reverse proxy that terminates TLS and authenticates users itself, so the JWT problem is bounded by the proxy's own session handling. Leave the command runner off; it is disabled by default, so the correct action is to not pass --disable-exec=false. Run it unprivileged in a container with only the intended directory mounted, which the shipped Dockerfile supports directly by setting USER user with UID and GID 1000 and declaring /srv, /config and /database as volumes.

The compose.yaml example is a reasonable starting shape for that, but note what it does not do: it publishes port 8000 on the host without a TLS terminator in front, and it mounts a named volume at /flux/vault rather than a host path. For a real deployment you would change both, mapping a specific host directory into the container and putting the published port behind your proxy instead of exposing it. The Redis service in that file exists to back the cache through FB_REDIS_CACHE_URL, and the comment notes rediss:// for TLS if you need it.

None of this makes the session model safe, and the README does not claim it does. It reduces exposure. That is the honest framing for software in this state, and it is the framing the project itself uses.

Editorial conclusion

Adopt File Browser only if you already run it, or if you need a small self-hosted file interface for a directory you are willing to expose through a reverse proxy that terminates TLS and authenticates users itself, with the command runner left off and the process running unprivileged in a container. Do not adopt it for internet-facing storage, for anything where revoking a session has to work, or for a fork you do not intend to maintain, because the README states there will be no further releases, bug fixes, or security fixes. Before you commit, verify the two items the README leaves open: that sessions are self-contained JWTs which cannot be revoked, and that the command execution feature is disabled by default and stays that way.

Frequently asked questions

Official sources

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