Why self-host FileBrowser on a VPS
FileBrowser is a web file manager written in Go, distributed as a single binary. It exposes a folder of your server in a modern interface: upload, download, preview, text editing, user management and share links. It's the ideal tool when a Nextcloud would be oversized: no external database, no PHP, a footprint of a few tens of megabytes. On a VPS, it becomes the web access point to your server data — delivering files to a client, granting scoped access to a folder, or simply managing an application's files without going through SFTP. A VPS is required because FileBrowser must read/write in the file system and run as a daemon, which shared hosting does not allow.
FileBrowser vs self-hosted alternatives
Scroll the table
| Criterion | FileBrowser | Nextcloud | Seafile |
|---|---|---|---|
| Database | Built-in SQLite | MySQL/PostgreSQL required | MySQL/PostgreSQL required |
| Minimum RAM | ~30 MB | ~500 MB | ~200 MB |
| Setup | One binary or Docker image | Multi-service Docker Compose | Multi-service Docker Compose |
| User management | Yes, with scopes | Yes, full-featured | Yes, full-featured |
| Desktop sync client | No | Yes | Yes |
| Expiring share links | Yes, built-in | Yes | Yes |
| Online editing | Text only | Text, Office (OnlyOffice) | No |
| Primary use case | Lightweight access & sharing | Full office suite | Bulk data sync |
Concrete benefits of self-hosted FileBrowser
- Ultra-lightweight: a Go binary, built-in SQLite database, starts in a few milliseconds.
- Fine-grained permission management: each user is confined to a subfolder (scope) with precise rights.
- Share links with password and expiry: send a file without creating an account for the recipient.
- Editing and preview in the browser (text, images, videos) without downloading.
- Custom commands and hooks: trigger a script on upload (conversion, antivirus scan).
- A clean web interface to replace SFTP for non-technical users.
- Native dark theme, responsive interface on mobile.
- Real-time filename search across the exposed directory tree.
Technical prerequisites
FileBrowser is one of the most resource-efficient tools: 1 vCPU and 512 MB of RAM are more than enough, with disk space depending solely on the volume of files to serve. No external database is required — the configuration and accounts are stored in a local SQLite file. You need Docker and Docker Compose, a files.yourdomain.com subdomain pointed at the VPS, and a reverse proxy for HTTPS. Important: plan which host folder you want to expose (a dedicated /srv/share folder, never the system root) and mount it as a volume in the container. Verify that ports 80 and 443 are open on your firewall, and that your VPS has a DNS A record (or AAAA for IPv6) pointing to its public IP.
Deploy FileBrowser step by step
Prepare the folders and the config
On the VPS:
mkdir -p /opt/filebrowser /srv/share. Create an empty file for the database:touch /opt/gtsteffaniak/filebrowser.db. The/srv/sharefolder is the one FileBrowser will expose. Adjust permissions so that the container UID can write to it:chown -R 1000:1000 /srv/share /opt/filebrowser.Write the docker-compose.yml
Base it on the
gtsteffaniak/filebrowser:latestimage. Mount/srv/share:/srv(the data),/opt/gtsteffaniak/filebrowser.db:/database/filebrowser.db(the database) and setPUID/PGIDto 1000 (or the actual UID of the shared folder). Expose the internal port 80 to the reverse proxy only — do not map directly to 80/443 on the host if Caddy or nginx is already using those ports. Addrestart: unless-stoppedso FileBrowser restarts automatically after a server reboot.Start and retrieve the credentials
Start with
docker compose up -d. On first launch, FileBrowser creates anadminaccount with a password shown in the logs:docker compose logs filebrowser. Note it down for the first login. If the logs don't show a password, log in withadmin/admin(the official image defaults) and change it immediately.Set up the reverse proxy and SSL
Place FileBrowser behind an HTTPS reverse proxy. With Caddy:
files.yourdomain.com { reverse_proxy filebrowser:80 }. The Let's Encrypt certificate is generated and renewed automatically. With nginx, create a dedicated vhost withproxy_pass http://127.0.0.1:<container_port>;and anssl_certificateblock pointing to certbot files. Make sure theX-Forwarded-Forheader is passed so FileBrowser logs the real client IPs in its access logs.Secure and create the accounts
Log in, immediately change the admin password, then create users limiting each to its scope (subfolder) with the appropriate rights. Enable the reverse proxy's two-factor authentication if the access is sensitive. In FileBrowser's settings, disable public registration (
allow registration: false) and restrict the authentication methods. For very restricted access, configure a basic auth layer at the reverse proxy level as an additional barrier.Test sharing and public links
Upload a test file, generate a share link with expiration (for example 7 days) and an optional password. Copy the link and open it in a private browser window to verify it works without an active session. Check that the expiration limit is properly enforced by inspecting the expiry time in the admin interface.
Securing FileBrowser in production
Exposing a file manager on the internet without additional security layers is risky. Several complementary measures apply depending on your context: restrict access by IP at the reverse proxy level if the tool is only meant for a team on a fixed network; enforce HTTP basic authentication in front of FileBrowser to add a barrier even before the application's login screen; enable detailed access logs to detect brute-force attempts. FileBrowser does not natively offer account lockout after N failed attempts: if your VPS is publicly exposed, a fail2ban rule on nginx or Caddy logs matching 401 responses is an essential complement. Finally, the exposed folder must be strictly separate from the home or system folder — FileBrowser only sees what you mount into it.
Security checklist before going live
- Admin password changed on first launch.
- Public registration disabled in FileBrowser settings.
- HTTPS reverse proxy active, HTTP→HTTPS redirect enforced.
- Each user limited to their own folder scope.
- Fail2ban (or Crowdsec) configured on reverse proxy logs.
- Default expiration enabled globally for all share links.
- Regular backups of
/opt/gtsteffaniak/filebrowser.db(accounts, config, permissions). - IP-based access restriction at the reverse proxy if users have fixed addresses.
Customizing FileBrowser: branding, commands and hooks
FileBrowser offers several levels of customization accessible from the admin interface. The Branding section lets you replace the logo, application name and colors — useful for delivering white-label access to clients. The Custom Commands section is one of the most powerful features: each scope can carry shell commands available at a single click in the interface. You can for example create a 'Compress to ZIP' command that calls a script and makes the archive downloadable. Hooks — before_copy, after_copy, before_rename, after_rename, before_upload, after_upload, before_delete, after_delete — allow automating actions without user intervention: generating a thumbnail on image upload, triggering a Slack webhook, launching a ClamAV scan, syncing to S3 object storage.
Backing up and updating FileBrowser
FileBrowser stores all its configuration in a single SQLite file: /opt/gtsteffaniak/filebrowser.db. This file holds accounts, scopes, permissions, share tokens and application settings. A daily backup of this file is sufficient to guarantee a full restore. Updating amounts to pulling the new Docker image: docker compose pull && docker compose up -d. FileBrowser automatically applies database migrations on startup — no manual intervention is required. Before any major update, copy the SQLite file outside the Docker folder to retain a safe rollback point. Check the project's GitHub changelog to identify breaking changes between versions, particularly any modifications to internal API URLs if you have scripts that rely on them.
Make use of FileBrowser's 'custom commands' to automate post-processing: for example, associate a script triggered on each upload (after_upload) that generates a thumbnail or launches a ClamAV scan. For client shares, always create a dedicated user with a reduced scope rather than sharing the admin account, and enable automatic expiry on public links so that no file remains accessible indefinitely. To automate SQLite backups, a daily cron with cp /opt/gtsteffaniak/filebrowser.db /backup/filebrowser-$(date +%F).db is sufficient — remember to purge copies older than 30 days to avoid filling the disk.
