Multiple mounted sources share one web interface
FileBrowser Quantum presents local directories and NAS mounts through a responsive browser interface. Users can browse, upload, edit, search, share, and preview files, with access controlled by user, group, source, and path. Password, OIDC, LDAP, JWT, proxy authentication, and two-factor login cover common identity setups. WebDAV and long-lived API tokens let other clients reach the same service. Shell commands are deliberately absent, reducing power for admins and risk for everyone else.
The repository we measured contained 854 files, about 162,620 lines of source, and occupied 16.2 MB before Go dependencies. That is a sizeable application rather than a thin directory listing page. The source covers a Go backend plus a modern interface, thumbnail generation, indexed search, activity records, sharing policy, and several authentication paths. Teams should test their actual media types and permission layout because feature breadth creates more policy combinations than a single-user file viewer.
Stable v1.5.6 and beta v2.0 use different databases
The project maintains two channels. The documentation recommends v1.5.x stable for new production users, while v2.0 is beta. Version 2 replaces the legacy database.db with filebrowser.sqlite and restructures configuration, so moving from stable requires a one-time migration. Pinning a full image tag gives the clearest rollback point. Tracking stable accepts later stable updates, while beta moves more often and should be treated as a test lane.
Our backend build completed in 73 seconds after an 89-second install. Those figures describe commit b12add4, not either container channel's startup or migration duration. The repository scan found seven CI workflow files, no Dockerfile, and no top-level tests directory. Published images and release binaries still exist, but an operator reviewing the supply path has to follow the workflows and documentation rather than finding a Dockerfile in the checkout we inspected.
What happened when we ran it
Our fresh Go 1.24 Bookworm sandbox installed 574 packages in 89 seconds. The backend under ./backend/ built successfully in 73 seconds. The checkout used an unprivileged container with 3 CPUs and 8 GB of RAM. We did not open the web interface, mount a NAS, generate thumbnails, connect an identity provider, or measure search and transfer speed. The result establishes buildability, not workload capacity.
Tests completed in 274 seconds with 50 passed and 0 failed out of 50. No install, compiler, or test error appeared in the supplied result. The full measured path took 436 seconds, which matters mainly to contributors and CI maintainers because users can choose a release binary or image. We did not run a vulnerability audit, so the passing suite should not be presented as a dependency-security result.
The Docker quick try starts with admin and admin
The stable Docker guide offers a fast trial on port 80 with admin as both username and password. It labels that path as a temporary evaluation, not regular deployment. Persistent use should mount the data directory that contains configuration, the database, and cache, then define only the file sources users should see. The docs specifically warn against mounting the host root or including /var, advice worth treating as a hard boundary.
The 16.2 MB repository footprint says little about persistent data growth. Thumbnail cache, search indexes, activity records, shares, and uploaded files depend on the mounted workload. Since v1.3, the container defaults to UID and GID 1000, so host permissions must match. Rootless engines may refuse port 80 without NET_BIND_SERVICE; using a higher internal port also means overriding the image healthcheck to probe that same port.
Large listings and a 170 MiB upload have open reports
Issue 2879 reports Chrome running out of memory when a folder contains thousands of files and suggests list virtualization. Issue 2877 describes a 170 MiB ZIP upload reaching 100 percent, then hanging while the target folder and host file explorer also become unresponsive. These are reports, not measurements from our sandbox, and they do not establish a universal size limit. They do identify two workloads that deserve a staging test with browser memory and server logs visible.
Our 274-second suite passed all 50 counted tests, but it did not perform either reported browser workload. Share behavior needs similar care. Issue 2888 says a password-protected v1.5.5 share still allowed a direct ZIP download without the password. The current latest release is newer, yet its notes do not name that issue. If shares protect sensitive files, verify browsing, direct downloads, expiry, anonymous access, and download limits against the exact pinned version.
The September 2026 release fixed an anonymous-read flaw
GitHub showed 8,181 stars, 189 open issues and pull requests, and a last push on September 8, 2026. Release v1.5.6-stable arrived September 4. Its security fix stopped a public metadata API from returning file content to anonymous share visitors when share download or viewer limits should have blocked it. The release also fixed a share-password reset and a loading spinner regression. The combined open count includes pull requests and feature requests, not 189 confirmed defects.
Active maintenance is visible in the release and September issue traffic. The clean 50-test run supports that picture, while 162,620 source lines and the busy queue argue for disciplined upgrades. Start on v1.5.6 stable or later, pin the chosen channel, back up the database before any v2 migration, and test the few file operations your users perform most. Quantum is strongest as a managed front end to trusted mounted storage, not as a universal replacement for every file protocol.