Deploy FileBrowser on Docker: Lightweight Web File Manager for Your HomeLab

Table of Contents

When SSH and SMB Fail at 2 AM

It is 2:15 AM on a Sunday. You are on hotel Wi-Fi with a 200ms ping when an alert fires: a 45GB backup archive on your storage node needs immediate verification.

You try opening an SFTP client, but NAT traversal on your travel router misbehaves. Next, you mount an SMB share over WireGuard, but the high latency throttles directory listings to a dead crawl. Full cloud platforms like Nextcloud can handle this, but their PHP-FPM pool and Redis cache easily chew through 2GB of RAM just to preview a config file.

You do not need a heavy collaboration suite to inspect or pull an urgent log file. You need a dedicated web file manager that boots in under two seconds, idles below 25MB of RAM, and runs cleanly inside a micro-container. That is where FileBrowser shines.

Why FileBrowser Fits Low-Overhead Stacks

FileBrowser is written in Go and packages cleanly into an alpine-based image under 40MB. Understanding how it handles state prevents permission headaches down the line.

Zero-Dependency Architecture

Self-hosted cloud suites often demand an external database (PostgreSQL or MariaDB), background Redis caches, and scheduled cron containers. In contrast, FileBrowser needs only two elements:

The Web Server Binary: A compiled Go executable serving an embedded Vue.js frontend with drag-and-drop uploads, audio/video streaming, and a built-in syntax-highlighted editor.
The SQLite Database (filebrowser.db): A single embedded database storing user logins, folder scopes, custom branding, and share tokens.

Direct Filesystem Passthrough

FileBrowser skips virtual storage layers and proprietary object formats. The directories you mount inside the container map straight to your host storage, whether that is a ZFS dataset, an unRAID share, or a local ext4 mount point. If you drop a 10GB ISO onto the server via rsync, FileBrowser shows it immediately without requiring an index rebuild.

Watch out for Unix file ownership. If your container runs as root (UID 0) while your media library belongs to a standard user (UID 1000), any file uploaded through the web UI gets written with root permissions. That locks out downstream services like Jellyfin or background backup scripts. Explicitly setting user permissions fixes this.

Step-by-Step Docker Deployment

Here is how to set up FileBrowser with persistent configuration and correct filesystem permissions using Docker Compose.

Step 1: Directory Setup and Database Initialization

First, create dedicated host directories for FileBrowser configuration and mapped storage:

mkdir -p /opt/filebrowser/config
mkdir -p /srv/storage

# Create an empty database file before launching Docker
touch /opt/filebrowser/config/filebrowser.db

# Assign ownership to your non-root user (e.g. UID/GID 1000)
sudo chown -R 1000:1000 /opt/filebrowser /srv/storage

Creating filebrowser.db before launching the container is essential. If Docker mounts a non-existent file path, it generates an empty directory with that name instead. That causes the Go binary to fail on startup when opening the SQLite file.

Step 2: Compose File Configuration

Create a docker-compose.yml file inside /opt/filebrowser/:

version: "3.8"

services:
  filebrowser:
    image: filebrowser/filebrowser:v2.30.0
    container_name: filebrowser
    restart: unless-stopped
    user: "1000:1000"
    ports:
      - "8080:80"
    volumes:
      # Root storage directory containing files you want to manage
      - /srv/storage:/srv
      # Persistent SQLite configuration database
      - /opt/filebrowser/config/filebrowser.db:/database/filebrowser.db
      # Custom configuration overrides (optional)
      - /opt/filebrowser/config/settings.json:/.filebrowser.json
    security_opt:
      - no-new-privileges:true

Step 3: Start and Verify

Launch the container in the background:

cd /opt/filebrowser
docker compose up -d

Check the container logs to verify the database initialized without permission errors:

docker logs -f filebrowser

You should see confirmation output like this within a second:

Listening on [::]:80
Using database: /database/filebrowser.db

Step 4: Initial Login and Hardening

Navigate to http://<your-server-ip>:8080 in your browser.

Default Credentials: Sign in with username admin and password admin.
Update the Admin Password: Head to Settings > Profile Settings and set a strong master password right away.
Restrict Shell Commands: Under Settings > Global Settings, verify that command execution remains disabled unless you explicitly need server-side shell triggers from the web UI.
Set Up Scoped Accounts: Go to Settings > User Management to add restricted users. You can lock an account to a subfolder like /srv/backups/work and revoke file deletion rights.

Step 5: Emergency Password Reset via CLI

If you lose access to the admin account, there is no need to wipe the database or delete your configuration. Reset the password directly inside the running container using the FileBrowser binary:

docker exec -it filebrowser /filebrowser users update admin --password "NewStrongPass2026!" --database /database/filebrowser.db

Summary

When storage incidents hit in the middle of the night, simple tools keep recovery fast and reliable. Running FileBrowser on Docker provides a web-based file portal that uses almost zero system resources, avoids database bloat, and interacts directly with your raw storage drives.