Best self-hosted file manager: FileBrowser vs Filestash

Wetín self-hosted file manager be, and wetín e no be

Self-hosted file manager na web page wey dey show directory tree wey already dey your VPS (virtual private server). You go log in, see /srv/files exactly as e dey for disk, then upload, rename, download, or give person link. Nothing dey copied enter another system, so file wey you drop for browser na the same file wey ls go show one second later.

Search results dey mix this one with software wey dey do other work. Sync tools dey keep copy of every file for every device, and na wetin self-hosted Dropbox alternative dey do. Object storage no get directory tree at all. E get buckets and API, so running MinIO for S3 compatible object storage dey answer different question. Server admin panels dey manage the machine, not the files. Na Cockpit and Webmin comparison dey cover that one.

You need file manager when colleague need one 300 MB archive from the server, or when you wan correct typo for config file with phone. The work small, and the tools too small.

Keep one fact for mind as you read. This one na web application wey get read and write access to your filesystem, and e dey listen on one port. Every choice below really dey decide how much of your disk that process fit reach.

FileBrowser don archive, so read this before you install am

FileBrowser, the filebrowser/filebrowser project, na the answer wey most guides still dey give. Its README now start with one notice:

File Browser don archive on 2026-09-01. The last planned release don already ship. No more releases, bug fixes, or security fixes go dey.

The Apache 2.0 code still dey work. But security fixes don stop. This matter pass for this category than for most others, because the software main purpose na to give write access to filesystem through HTTP.

The maintainers write down how to continue using am, and the advice good to follow no matter which tool you choose: no expose am directly to internet, put am behind reverse proxy wey terminate TLS (transport layer security) and do its own authentication, keep the command runner disabled, and run am unprivileged inside container with only the directory wey you intend to serve mounted inside am.

One line for that README matter pass the rest. Sessions na self-contained JWTs (JSON web tokens), instead of server-side identifiers, so you no fit revoke dem. If session token leak, e go remain valid until e expire, and changing password no go kill am. If you continue to use FileBrowser, the authentication layer wey dey in front of am na the one wey dey do the real work.

FileBrowser Quantum: fork wey still dey move

Active development don move go one fork, FileBrowser Quantum (gtsteffaniak/filebrowser), wey dem publish as the gtstef/filebrowser image. E rebuild configuration around one single config.yaml instead of the older mixture of command line flags and database settings. The documented quick try be:

docker run -d \
  -v $(pwd):/srv \
  -p 80:80 \
  gtstef/filebrowser:beta

This one serve the current directory for http://localhost, and the first login na admin / admin. Change am before container fit reach from anywhere apart from your own machine.

For instance wey you go keep, use Compose, mount the data directory instead of one database file, and bind the port to localhost:

services:
  filebrowser:
    image: gtstef/filebrowser:beta
    user: "1000:1000"
    volumes:
      - /srv/files:/folder
      - ./data:/home/filebrowser/data
    ports:
      - 127.0.0.1:8080:80
    restart: unless-stopped

The config dey for /home/filebrowser/data/config.yaml and the database dey for /home/filebrowser/data/filebrowser.sqlite. Version 2.0.0 change the database format and dey do one-time migration. Na why the docs ask for directory mount: single file mount no give the migration place to put the new file. The paths inside config.yaml na container paths, so source for the config dey read /folder, no be /srv/files. If you mix this up, e go produce empty file list without error, because the directory truly no dey there.

The project publish latest and stable for around 60 MB with FFmpeg bundled for video thumbnails, and stable-slim for around 15 MB with core only. Na these figures dey for the install page for August 2026. Pin the tag wey you choose. latest fit change without telling you, and file manager wey change im config format while container dey run fit spoil your morning.

For this work, na the strongest among the small tools. E serve multiple sources with include and exclude rules, so one instance fit expose /srv/media and /srv/docs with different scope. Shares get expiration time, and dem fit be anonymous or restrict dem to one user. Authentication cover OIDC (OpenID Connect), LDAP (lightweight directory access protocol), password with two factor, and proxy header mode. Na this proxy mode make e fit sit behind single sign on (SSO) from self-hosted Authentik server instead of keeping another list of users.

Filestash: one interface over storage wey you already get

Filestash na different kind of tool. E be front end wey dey connect to backend, and the backend list long: FTP, SFTP (SSH file transfer protocol), S3, SMB, WebDAV, IPFS and about twenty more. E useful when the files no dey the same box wey dey run the interface.

mkdir -p /srv/filestash && cd /srv/filestash
curl -O https://downloads.filestash.app/latest/docker-compose.yml
docker compose up -d

The image na machines/filestash:latest. Open http://your_domain:8334 and the first screen go set the admin password. Set am immediately, because until you do am, anybody wey find the port fit enter the admin console.

Understand the identity model before you build anything on top of am. Filestash no dey keep user database for the usual way. Credentials dey stored for your browser through cookies wey encrypted, authenticated and HTTP only, and nothing dey kept for server side unless you use the share feature. For that case, Filestash dey keep persistent encrypted version of your credentials. The "users" na storage accounts: identity dey for the backend, inside the SFTP account or the S3 key, no be for Filestash.

This design clean, but e get cost. The pricing page list the free self-hosted tier as AGPL v3 (GNU Affero General Public License) with up to 3 users. E put SSO (SAML, OIDC and LDAP) with role based access control for the paid self-hosted tier from $50 per month, as of August 2026. If your plan na "Filestash in front of company SSO, for free", check that page before you design around am.

SFTPGo: protocol server wey get web interface too

SFTPGo na the software wey get the most capability here, and na the one people dey recommend most times for wrong reason. E dey serve SFTP, HTTP/S, FTP/S and WebDAV over local filesystem, encrypted local filesystem, S3 compatible object storage, Google Cloud Storage, Azure Blob Storage, or another SFTP server.

Dem don publish binaries, Debian and Ubuntu packages, plus container image. The current APT repository line and signing key dey for installation page inside SFTPGo documentation. Container route na the fastest way to make am dey run. Replace tag with the version wey you want:

docker run --name some-sftpgo -p 8080:8080 -p 2022:2022 -d "drakkan/sftpgo:tag"

SFTP dey listen on 2022, while the web interfaces dey listen on 8080. Mount /srv/sftpgo as a volume. Otherwise the accounts and their files go disappear when dem recreate the container, because user home directories dey default to /srv/sftpgo/data/<username>.

Two web interfaces dey, and the difference na the part wey most write-ups no explain clearly. WebAdmin, for /web/admin, na for administration. Na there you create users, groups, virtual folders and event rules. You also set quotas, bandwidth limits and access time restrictions there. WebClient, for /web/client, na the end user view. Na there person fit browse files, change their own credentials, set up two factor authentication and create shares.

Those shares na the best feature for this comparison. User fit create HTTP/S links to share files and folders, limit the number of downloads and uploads, protect the share with password, limit access by source IP address, and set automatic expiration date.

So why we dey advise caution? The main focus na the account model and protocol server, not the browsing experience. Choose SFTPGo when other people need real accounts with quotas, when uploads dey arrive over SFTP or FTPS from system wey you no control, or when one bucket need appear inside home directories of several users. Virtual folders handle that last case: folder wey local disk, S3, GCS, Azure Blob, SFTP or HTTP dey back, mounted into multiple accounts, with separate quota for each user on shared folder. If na only browsable page over /srv/files you want, this na plenty machinery for that purpose.

Two more facts dey worth knowing. Community edition na AGPL-3.0-only with additional terms, while commercially licensed Enterprise edition dey available too. OIDC login dey inside the open source build. E maps identity provider users to SFTPGo admins and users for both web interfaces. You fit also turn off the client interface globally with enable_web_client inside httpd configuration. Or you fit do am per user by adding HTTP to that user's denied protocols. This one make the file manager dey available for one person but no dey available for everybody.

Cloud Commander: panes two and terminal, for one person

Cloud Commander na MIT licensed Node.js manager wey dey use panes two style, with editor wey dey inside, console and terminal. Install am globally with npm i cloudcmd -g, or run the published container:

docker run -it --rm -v ~:/root -v /:/mnt/fs -w=/root -p 8000:8000 coderaiser/cloudcmd

Read that command well before you run am. -v /:/mnt/fs mount the whole host filesystem inside the container, and the sample ~/.cloudcmd.json get "root": "/", "auth": false and "console": true. That combination mean anybody wey reach port 8000 go get access to your whole disk and command console for the server. E fit make sense for laptop, but e no good for VPS.

Reduce the scope. The container dey read /root/.cloudcmd.json, wey the published command provide by mounting your home directory, so keep the config mount and remove the others:

docker run -d --name cloudcmd \
  -v ~/.cloudcmd.json:/root/.cloudcmd.json \
  -v /srv/files:/srv/files \
  -w=/srv/files \
  -p 127.0.0.1:8000:8000 \
  coderaiser/cloudcmd

For that config file, set "root" to /srv/files, "auth" to true with a "username" and "password", and set "console" and "terminal" to false unless you really want browser shell access. Command line equivalents dey too, including --root, --auth, --username, --password and --prefix.

Make you understand wetin e be. Na one credential pair, e no get per user scoping, quotas, or share links. Na personal tool, so bind am to localhost as above and reach am through a tunnel:

ssh -L 8000:127.0.0.1:8000 you@your-vps

Then open http://127.0.0.1:8000 for your own machine. Nobody expose the file manager publicly, and the only thing wey face internet na the SSH daemon wey you already harden for your VPS.

Why Nextcloud no be the correct tool for this one work

Nextcloud na good software, but e no be this one. Na collaboration platform: PHP application, database, background jobs, desktop sync clients and app store. To run am just to get web view of /srv/files na plenty moving parts for small work, and one specific mismatch dey. Nextcloud dey keep file metadata for database table instead of reading directory for every request. So files wey rsync or cron job write fit remain invisible for the interface until scan catch up, with sudo -u www-data php occ files:scan --all. File manager dey list directory when you load page, so that gap no dey.

Keep Nextcloud for wetin e good at: calendars, contacts, sync and sharing with people wey expect desktop client. Nextcloud for VPS with Docker, TLS and backups cover that setup. If you don already dey run am and you only need see existing directory, enable External Storage app and stop there. Another web application wey get write access to the same disk na another thing wey you need patch.

How to run one without giving away the whole server

Never point am go /. The process fit read and write everything wey the user account fit reach. So if person steal session token, e go get exactly that level of filesystem access. Serve only one directory, /srv/files, and create the directory specifically for this purpose.

Run am with non-root user and mount only wetin e dey serve. For Compose, na user: "1000:1000" plus one bind mount for each directory. Add :ro to anything wey e no need write:

    volumes:
      - /srv/files:/folder
      - /srv/media:/media:ro

Usually, after this change, browsing go work but uploads go fail with permission denied. The reason be say the user id inside the container no own the directory outside the container. Compare both sides: docker exec filebrowser id go print the container user, while ls -ln /srv/files go print the numeric owner for the host. Use sudo chown -R 1000:1000 /srv/files to fix am. Na this same ownership problem PUID and PGID for Docker images dey solve.

Bind the published port to localhost, 127.0.0.1:8080:80, instead of 8080:80. Docker dey write its own netfilter rules before ufw rules, so plainly published port fit still dey reachable from internet even when ufw deny 8080 dey active. Put reverse proxy in front for TLS. With plain HTTP, session cookie dey pass through network in clear text, and that cookie na filesystem access. If Compose still new to you, Docker Compose for VPS explain the file layout wey these snippets assume.

Add authentication layer when the application's own authentication too limited. HTTP basic auth for the proxy dey enough for one user instance. Once more than one person dey use am, use OIDC or forward auth against identity provider. That way, revoking one account go revoke access everywhere.

Turn off the extra features. Any file manager wey offers shell, command runner, or in-browser terminal dey offer remote code execution to anybody wey get valid session. FileBrowser guidance say make command runner stay disabled, while Cloud Commander's sample config enables the console. Decide this deliberately; no use the default setting.

Wetin go first spoil, and the errors wey you go see

listen tcp :80: bind: permission denied. Linux reserve ports below 1024 for privileged processes. FileBrowser Quantum documented config use port 80, and e dey work inside container but e go fail immediately if you run the binary as unprivileged user for the host. Set port wey pass 1024 inside config.yaml and make the proxy handle 443.

Uploads fail while browsing works. To list directory, you need r-x. To write inside am, you need w. Web interface go show general error, so check filesystem first instead of application logs.

413 Request Entity Too Large. Nginx na the source of this error, not the file manager. Default client_max_body_size na 1 MB, so proxy go reject bigger upload before application even see am. Set client_max_body_size 4096m; inside the server block, or use 0 to disable the check.

Uploaded files carry the wrong group. Process user go own new files, no matter wetin the surrounding directory set, and this fit stop another service from reading the same tree. Give both services one shared group and set the setgid bit on the directory with sudo chmod g+s /srv/files, so new files inherit the directory group.

Everything works on the port and breaks behind the proxy. Application wey dey serve under subpath dey build links from prefix wey you need tell am about. Cloud Commander get --prefix for this. If no such option dey, give the application its own subdomain and proxy the root path.

Wich self-hosted file manager you suppose run?

• One VPS, one or two directories, share links wey get expiry, and maybe SSO later: FileBrowser Quantum.
• Files wey dey somewhere else, like S3 bucket, SFTP host, or NAS over SMB, and you want one web view across all of dem: Filestash, as long as e dey within free tier limits.
• If other people need accounts, quotas, and uploads over SFTP or FTPS: SFTPGo. Treat the web client as useful extra, no be the main reason you choose am.
• Personal tool wey get editor and terminal, accessed through SSH tunnel and never published: Cloud Commander.
• If Nextcloud already dey run and you get existing directory wey you want expose: use the External Storage app, and no install any new software.

No matter the one you choose, deployment matter pass the choice. Use one directory, one non-root user, one port wey bind to localhost, and authentication for front. File manager wey you set up like this na convenience tool. The same software wey point to / with shared password na remote shell with fine interface.

FAQ

FileBrowser still safe to run in 2026?

The upstream filebrowser/filebrowser README talk say File Browser don archive am on 2026-09-01, and no more releases, bug fixes or security fixes dey come. The code still dey run, but unpatched software wey get write access to your filesystem na risk wey dey increase with time. If you keep am, follow the project own advice: no direct exposure to internet, make reverse proxy handle TLS and its own authentication, leave the command runner disabled, and use unprivileged container wey mount only the directory wey e dey serve. Also note say its sessions na self-contained JWTs, not server-side identifiers. So you no fit revoke dem, and changing password no invalidate token wey don already issue. For new install, use the FileBrowser Quantum fork, wey dem publish as the gtstef/filebrowser image, because development still dey continue.

Self-hosted file manager fit use my existing SSO?

FileBrowser Quantum supports OIDC, LDAP and proxy header mode. So e fit sit behind existing identity provider without needing second user list. SFTPGo's OpenID Connect integration dey inside the open source build. E maps identity provider users to SFTPGo admins and users for both the WebAdmin and WebClient interfaces. Filestash na the exception wey you need watch: its pricing page put SSO (SAML, OIDC and LDAP) for the paid self-hosted tier from $50 per month as of August 2026, while the free tier dey listed as AGPL v3 with up to 3 users. If application no get SSO support at all, the fallback na forward authentication for reverse proxy. This one protects the login page, but e no change the application's internal permissions.

Which one get share links wey dey expire?

SFTPGo get the most complete implementation. User fit create HTTP/S link from the WebClient, limit the number of downloads and uploads, set password, restrict access by source IP address, and set automatic expiration date. FileBrowser Quantum supports shares with expiration time. Access fit be anonymous or restricted to one user, plus per-share permissions for viewing, editing and uploading. Filestash get share feature too. Na the only case where server keeps persistent encrypted copy of storage credentials, because the link must work after your browser session don end. Cloud Commander no get share links at all.

E safe to point file manager at / if na only me be the user?

No. The risk no really depend on whether you trust yourself. The process gets read and write access to everything wey its user account fit reach. Any path into that session, stolen cookie, unpatched bug for upload handler, or reused password fit turn into access to /etc, your SSH keys, and every service data directory. Limit the mount to one directory instead: /srv/files rather than /. Cloud Commander na where this problem worst, because its published Docker command mounts the host root at /mnt/fs and its sample config sets "root": "/" with "auth": false. Change both before that container listens on anything except localhost.