How to Self-Host File Browser in 2026: Volumes, Accounts and Safe Sharing

Treat File Browser as a small system, not a Docker image. The user-facing goal for File Browser is clear: web file manager for an attached volume; the deployment is acceptable only when you can create a restricted user, upload and rename a file, edit text, generate a share and confirm the user cannot escape its assigned root.

That distinction catches the failure mode operators meet after local testing: the mounted files use host permissions the container cannot read. It also makes the backup and upgrade plan specific enough to test.

Find every durable byte in File Browser

A container image can be downloaded again; the served files plus the File Browser database and settings cannot. Mount /srv before bootstrap, write harmless sample data and replace the container to prove that path is actually persistent. Inspect the effective mount instead of trusting a Compose filename, and check that the runtime user can write where File Browser expects.

Choose retention and an off-host destination, then rehearse recovery without touching production. The drill passes only when served files, users, scopes, shares and settings return and a restricted account remains confined. For database-backed state, pair storage snapshots with application-consistent exports as described in point-in-time recovery versus snapshots.

Run the first production-shaped instance

Keep the initial File Browser invocation reproducible enough to review in a pull request.

docker run -d \
  --name file-browser \
  --restart unless-stopped \
  -p 127.0.0.1:80:80 \
  -v file-browser-data:/srv \
  -v file-browser-db:/database \
  -v file-browser-config:/config \
  filebrowser/filebrowser:latest

Do not rely on latest after real data exists. Capture the working digest, container user and mount ownership. Follow the application log through a complete test — create a restricted user, upload and rename a file, edit text, generate a share and confirm the user cannot escape its assigned root — and note any migrations before putting the route behind production traffic.

Draw the File Browser runtime boundary

Process health and product health are separate for File Browser. Port 80 may answer while the user-facing transaction still fails. The local runtime requirement is a separate persistent path for its database and settings. Validate it under the acceptance workload; an idle health check cannot prove that the resource is sufficient.

Use this readiness exercise after meaningful configuration changes: create a restricted user, upload and rename a file, edit text, generate a share and confirm the user cannot escape its assigned root. Keep expensive external checks out of liveness probes so a provider outage does not cause a restart loop. Capacity work should track underlying disk throughput, upload size, concurrent downloads and directory counts, which is closer to File Browser's real pressure than page requests.

Make the public origin unambiguous

Expose one HTTPS hostname for File Browser; keep raw port 80 private. Publish the UI over HTTPS but scope the served root carefully. This prevents browsers and API clients from learning two competing addresses.

From a clean client, run the known-good transaction and inspect the first failing request. Use the custom-domain guide when DNS or TLS is wrong. Treat “the mounted files use host permissions the container cannot read” as a separate application diagnosis once the route is proven.

The File Browser release gate

Create a small, disposable File Browser fixture and keep it for every release. The fixture should exercise the real workflow: create a restricted user, upload and rename a file, edit text, generate a share and confirm the user cannot escape its assigned root. Record the image digest, external hostname, dependency address and the expected result so a later operator can repeat the test without interpreting this guide.

Run the fixture three times. First, use the fresh deployment. Second, replace the container without touching durable state. Third, restore the backup into an empty environment. The third run passes only when served files, users, scopes, shares and settings return and a restricted account remains confined. During each run, capture latency and resource use around underlying disk throughput, upload size, concurrent downloads and directory counts; this becomes the baseline for alerts rather than an arbitrary CPU percentage.

Finally, test the negative path deliberately: submit harmless input near the resource or format limit associated with this boundary: the mounted files use host permissions the container cannot read. Confirm that File Browser fails visibly without corrupting state, restore the correct condition and repeat the successful transaction. A release record containing those four outcomes is stronger evidence than screenshots of a dashboard or a one-time curl response.

Capacity and upgrade checks

An idle health check says little about File Browser. Watch underlying disk throughput, upload size, concurrent downloads and directory counts, then alert on the symptom users experience: failure of the action “create a restricted user, upload and rename a file, edit text, generate a share and confirm the user cannot escape its assigned root”. Keep liveness local and cheap; let readiness report migrations or initialization without causing a restart storm.

The risky upgrade area is that File Browser database and settings migrations matter even though the served files live on a separate mount. Read release notes, snapshot state, deploy the target version against a restored copy and repeat the acceptance action. If the mounted files use host permissions the container cannot read, correlate the client request with the first relevant application log rather than deleting state or adding redirects blindly.

Reduce the authority held by File Browser

Bootstrap credentials are temporary; the trust model is permanent. With File Browser, watch for serving / or a secrets directory instead of a dedicated share, and serve a dedicated directory instead of the host root and give each account the narrowest file scope it needs.

File Browser has no mandatory bootstrap secret in this baseline; protect its actual administrator account or upstream authentication instead. Run the image without unnecessary Linux capabilities and expose only the public application route. Keep administrator activity visible without recording secret values.

Use Dockup for the platform layer

For File Browser, Dockup is most useful at the boundary between an image and a durable service. It keeps the route to 80, TLS, secret values and storage attached across container replacements, whether the compute belongs to Dockup or to your attached server.

Finish with application knowledge: publish the UI over HTTPS but scope the served root carefully; confirm the local requirement — a separate persistent path for its database and settings; and run this verification: create a restricted user, upload and rename a file, edit text, generate a share and confirm the user cannot escape its assigned root. Keep the result as a deployment check so the next image update is judged by behavior rather than by container status.

Frequently asked questions

What does File Browser need for a production deployment?

Route the File Browser container on port 80 through one HTTPS origin. The local runtime requirement is a separate persistent path for its database and settings. Do not call File Browser ready until you can create a restricted user, upload and rename a file, edit text, generate a share and confirm the user cannot escape its assigned root.

Which File Browser data belongs in a backup?

Persist /srv and include the served files plus the File Browser database and settings in the same recovery manifest. A clean File Browser restore passes only when served files, users, scopes, shares and settings return and a restricted account remains confined.

Does File Browser require HTTPS behind a reverse proxy?

Use HTTPS for the public File Browser origin and keep port 80 on the internal route. Apply the File Browser setting correctly: publish the UI over HTTPS but scope the served root carefully. For File Browser, HTTPS protects credentials or user content in transit and keeps origin-sensitive client behavior consistent.

How should a File Browser upgrade be tested?

Restore current File Browser state into an isolated deployment, apply the candidate version and repeat its acceptance transaction. Pay particular attention because File Browser database and settings migrations matter even though the served files live on a separate mount. Keep the previous File Browser image until its data-migration and rollback boundary are understood.