Install File Browser With Docker Compose for Simple Web File Access

Before you begin

• A Docker host with Compose.
• A single host directory you actually want to expose, such as /srv/shared-files.
• A private hostname or authenticated reverse proxy plan.
• Enough discipline not to mount broad system paths just to save 30 seconds of thought.

File Browser's docs still describe a Docker image that expects one mount for the served files, one for the database, and one for config. The Docker run example maps them to /srv, /database, and /config, with the default configuration and database initialized automatically on first boot.

Step 1: Prepare a narrow file root

Create the directory you want File Browser to expose:

sudo mkdir -p /srv/shared-files
sudo chown -R $USER:$USER /srv/shared-files

Put only the files you are comfortable serving through the web UI inside that path. If you need multiple unrelated areas, think carefully before combining them behind one admin surface.

Step 2: Create the Compose stack

Create a stack directory and save this as compose.yaml:

mkdir -p /opt/stacks/filebrowser
cd /opt/stacks/filebrowser

services:
  filebrowser:
    image: filebrowser/filebrowser:latest
    restart: unless-stopped
    ports:
      - 127.0.0.1:8085:80
    volumes:
      - /srv/shared-files:/srv
      - ./database:/database
      - ./config:/config

This Compose layout is the direct equivalent of the official Docker run example. The main difference is that we keep the service on a local-only host port until private access is in place.

Step 3: Start File Browser and finish first boot

Start the service:

docker compose up -d
docker compose ps

Then inspect the created paths:

ls -la ./database
ls -la ./config
docker logs filebrowser --tail 100

The first boot should initialize the default configuration and database automatically. Before exposing the service more broadly, sign in privately and change the default credentials or create the intended user accounts according to the current admin workflow.

Step 4: Secure the service and access path

File Browser is one of those tools where access discipline matters more than aesthetic perfection. Good patterns include:

• Localhost bind plus SSH port forwarding
• A private network such as Tailscale
• A reverse proxy with authentication and TLS

A simple Caddy example:

files.example.com {
  reverse_proxy 127.0.0.1:8085
}

If several people will use it, define the permission boundaries early. A simple web file manager becomes a liability fast when everyone shares one overpowered account.

Step 5: Operate, back up, and update it

Routine checks:

docker compose ps
docker logs filebrowser --tail 50
du -sh /srv/shared-files ./database ./config

To update the image:

cd /opt/stacks/filebrowser
docker compose pull
docker compose up -d

Back up the served files plus the database and config directories together. The files are the content. The database and config define how the app sees that content.

Rollback notes

A rollback is usually just a previous image tag plus the same persistent directories. If a configuration experiment breaks access, keep the content mount intact and revert only the app layer first.

If permissions suddenly stop working, confirm the host directory ownership and the exact mount targets before assuming corruption.

Troubleshooting

The app starts but no files appear.
Verify that the intended host directory is mounted to /srv and actually contains readable files.

Settings or users vanish after recreation.
Make sure /database and /config are backed by persistent paths, not ephemeral container storage.

You accidentally exposed sensitive files.
Stop the stack immediately, fix the bind mount, and rotate any secrets that may have been reachable.

You want collaborative document editing and sync.
File Browser is not a full team cloud suite. Use a heavier tool if that is the real requirement.