FileGator: a self-hosted multi-user file manager with no database

The gap FileGator fills between raw SFTP and a full sync platform

The README frames FileGator as a replacement for FTP or SFTP when the people on the other end should not be handed SSH credentials. That is a narrower goal than it first appears. Most self-hosted file tools either sync a folder to every device or turn into a document suite; FileGator stays a web UI over a storage backend. Users get copy, move, rename, edit, create, delete, preview, zip, unzip, download and upload, and nothing else competes for their attention.

The audience follows from that. The README lists sharing a folder with colleagues, collecting student uploads, gathering field data and images from workers, using it as cloud backup, and giving several people access to a CDN. In each case one administrator defines accounts and home folders, and the users only ever see the browser. The project is MIT licensed, so the constraint is operational rather than legal: you host it, you patch it, you own the accounts.

Storage, auth and session adapters behind one PHP application

FileGator is assembled from three replaceable layers, and the README names the library behind each. Storage goes through Flysystem, so Local, FTP, Amazon S3, Dropbox, DO Spaces and Azure Blob are adapters rather than features. Authentication supports roles and permissions with users stored in a JSON file, a database, or WordPress. Sessions are handled by Symfony's HttpFoundation, which brings Native File, Pdo, Redis, MongoDB and Memcached handlers.

The front end is a single-page application built with Vue, Bulma and Buefy. Uploads use Resumable.js, which is why the README can promise drag and drop, a progress bar, pause and resume, and chunked transfer that should work for large files regardless of server configuration. The repository layout matches this split: backend/, frontend/, dist/ for the built assets, plus configuration_sample.php at the root. The Dockerfile shows the build order plainly, running composer install, then composer require for league/flysystem-sftp and league/flysystem-aws-s3-v3, then npm install and npm run build. The production stage installs the zip, ldap and mysqli extensions, which tells you which auth and storage paths the shipped image expects to be usable. No database is required for the default setup.

Installing FileGator with Docker and logging in for the first time

The README gives a single command for the official image. It publishes port 8080 and removes the container when it stops, so nothing persists between runs:

docker run --rm -p 8080:8080 filegator/filegator

After that, the README says to visit http://127.0.0.1:8080 and log in as admin/admin123. Those credentials are the default and the README states them openly, so change them before the instance is reachable from anywhere but your own machine.

For anything you intend to keep, the repository's docker-compose.yml is the better starting point. It declares a filegator service on port 8080 and mounts two named volumes, repository and private:

services:
  filegator:
    build: .
    image: filegator:latest
    restart: always
    ports:
      - "8080:8080"
    volumes:
      - repository:/var/www/filegator/repository
      - private:/var/www/filegator/private

The repository volume is the storage users see. The private volume holds the application's own state, including the JSON user file when you use the file-based auth adapter. Both need to survive container replacement, which is exactly what the named volumes provide and what the one-line docker run does not.

To build from source instead, package.json defines a serve script that installs Composer and npm dependencies and runs the PHP server on 8081 alongside the Vue dev server on 8080:

npm run serve

That script is for development. The Dockerfile is the path to a production image, and it also runs vendor/bin/phpunit and npm run lint during the build, so a broken test or lint failure stops the image from being produced.

Symlinks, chown and crowded directories are documented dead ends

The README keeps a short Limitations list, and it is unusually honest. Symlinks are not supported because the underlying Flysystem local adapter does not support them. File ownership is not supported, so chown is not something you can drive from the interface. And too many files in the same directory can negatively impact performance.

The third point deserves more weight than the other two. A directory listing is the primary screen of a file manager, and the README offers no threshold, no pagination setting and no index to work around it. If your use case is a drop folder that accumulates tens of thousands of uploads, FileGator is the wrong tool and the project says so in one line. The first two limits are architectural: no symlinks means you cannot stitch together storage trees that live elsewhere on the filesystem, and no ownership means file permissions come from the web server process rather than from the user who uploaded the file.

There is a second class of limitation the README does not discuss: the default account is admin/admin123, and the security section directs vulnerability reports to GitHub Security Advisories rather than the public issue tracker. That tells you the project takes reports seriously, but it does not tell you anything about how quickly fixes ship. The CHANGELOG.md at the repository root is where release history lives.

FileGator compared with filebrowser and Nextcloud

The closest comparison is filebrowser, which also presents a web file manager over a directory tree. The difference is in the extension model. FileGator routes storage through Flysystem and sessions through Symfony, so pointing it at S3, Dropbox or DO Spaces is a configuration change rather than a fork. It is also a PHP application, which matters if your servers already run PHP and you would rather not add a second runtime. If your storage is a single local disk and you want the smallest possible binary, filebrowser is the leaner choice.

Nextcloud sits at the other end. Nextcloud is a sync and collaboration platform with a database, desktop and mobile clients, calendars and contacts. FileGator has none of that, and the README does not claim otherwise. It has no database requirement and no sync client, which is the whole point: users open a browser, work with files, and close the tab. Choose FileGator when the job is browser access to a storage backend, and choose a sync platform when the job is keeping copies on every device.

The Dockerfile also carries a practical signal about scope. It installs the ldap and mysqli extensions in the production stage, which points at directory-based login and database-backed users as supported configurations. Those extensions are present in the shipped image rather than left to the operator to add.

Licence, release cadence and what an upgrade costs

FileGator is MIT licensed, copyright Milos Stojanovic, starting in 2019. MIT is permissive: you can run it commercially, modify it and redistribute it, provided the copyright notice and licence text travel with it. That is the licence text, not legal advice, and anything you build on top of the codebase is your own responsibility.

The release history in the repository shows v7.16.2 on 2026-09-07, v7.16.3 on 2026-09-14 and v7.16.4 on 2026-09-20. The last push to the default branch was on 2026-09-20. Three patch releases in two weeks is a maintenance rhythm worth noting, and it also means upgrade cost is mostly the cost of pulling a new image and restarting. The Dockerfile is the reason: the front end is compiled into dist/ during the build, so you are not expected to run npm on your production host.

The part that does not upgrade itself is your configuration. configuration_sample.php at the root is the template, and the Dockerfile copies it to configuration.php during the build. If you mount your own configuration.php, or keep users in a JSON file under private/, that state persists across image updates and is what you should back up before pulling a new tag. There is no documented migration step for configuration changes between releases, so read CHANGELOG.md before moving a production instance.

Editorial conclusion

Adopt FileGator if you need a small, database-free file front end over local disk or an object store and you are willing to keep users in a JSON file or your own auth adapter. Skip it if you need symlinks, per-file ownership, or directories holding very many files, because the README lists all three as unsupported or slow. Before rolling it out, run the Docker image, log in as admin/admin123, and change that password and the private/ permissions.

Frequently asked questions

Official sources

1. filegator/filegator on GitHub
2. License: MIT
3. Project website
4. README
5. Releases