FileRise: a PHP file manager where ACLs, WebDAV and encryption share one permission model
🗂️ FileRise – lightweight, self-hosted file manager & storage hub with granular ACLs, resumable uploads, encrypted folders, WebDAV & SSO. Fully Docker / Unraid compatible.
At a glance
- What is it?
- FileRise is a self-hosted file manager and storage hub written in PHP, distributed mainly as a Docker image, with per-folder ACLs enforced across the web UI, the API and WebDAV. The MIT core covers the file manager; groups, client portals, automation and an AI workspace sit behind the Pro tier.
- Who is it for?
- Adopt FileRise if you want a self-hosted file manager where permissions are the product rather than an afterthought, and you accept that the MIT core stops short of groups, client portals and the AI workspace. Do not adopt it if you need a database-backed metadata layer, a sync client, or encrypted folders that still support WebDAV and ZIP operations, because the README states those features are automatically disabled when folder encryption is enabled.
- Can I use it commercially?
- Yes. MIT is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository last received commits 22 days ago.
- What is it written in?
- Mainly JavaScript, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The gap FileRise fills: permissions that survive the trip to WebDAV
Most self-hosted file managers treat sharing as a link generator. You get a public URL, maybe a password, and the permission model lives inside the web application. The moment someone mounts the same storage over WebDAV or calls the HTTP API, the rules change, because those surfaces were bolted on afterwards. FileRise is aimed at that gap. The README describes per-folder ACLs covering View (all or own), Upload, Create, Edit, Rename, Move, Copy, Delete, Extract and Share, and states they are enforced consistently across the UI, API and WebDAV. That consistency claim, not the feature list, is the reason to read further.
The target user is someone running their own infrastructure who wants a browser-based drive with real permissions: a homelab operator on Unraid, a small team that wants a client portal without a SaaS subscription, or an administrator who needs an upload-only drop folder for external contributors. The README frames it as a file manager, storage hub, client portal and AI workflow workspace. Only the first two are in the MIT core; the portal and AI workspace are Pro features, and the README is explicit about that split.
One architectural decision shapes everything else: no external database is required. That keeps the deployment small and the backup story simple, but it also means metadata lives alongside the files rather than in a queryable store. For a project of this scope that is a reasonable trade, and it is the reason the Docker path is the recommended one.
How the pieces fit: PHP app, multiple roots, one ACL check
FileRise is a PHP application. The Docker image is the recommended distribution, and a manual install on a standard PHP web server is documented as an alternative. Storage is not a single directory: the README mentions multiple local roots and WebDAV sources for storage-hub workflows, which means the app can present several backing locations under one interface. The Pro tier adds additional source adapters, so the core set is narrower than the full list.
Uploads are chunked and resumable. The README states that if the connection drops, FileRise resumes automatically, and that pause and resume are available with progress tracking. That is a client-side chunking scheme rather than a single POST, which matters for large files over unreliable links.
Encryption is the most consequential mechanism. It is opt-in per folder, inherited by subfolders, and files are stored encrypted on disk and transparently decrypted on download. The master key can be generated by FileRise or supplied through an environment variable. The README is unusually direct about the cost: when encryption is enabled, WebDAV, sharing, ZIP operations and OnlyOffice are automatically disabled for safety. This is not a bug to work around. It suggests the encryption layer wraps file reads and writes at a point those features cannot use.
The ACL model itself is per folder, with View split into all or own. That is a coarse but predictable design. It does not appear to support role inheritance beyond folder nesting, and the README does not describe a group concept in the core. Groups are listed under Pro. If your permission model needs groups in the open-source build, that is a gap you should confirm before deploying.
Install: the Docker path, the manual path, and the five-minute checklist
The README recommends Docker and links to a separate repository, error311/filerise-docker, for the image. The cleaned README text does not include the literal docker run command, so the exact flags are not reproduced here. The image is published as error311/filerise-docker on Docker Hub, and Unraid compatibility is stated in the repository description and topics. Treat the Docker Hub page and the filerise.net/docs install section as the authoritative source for volume paths and port mappings rather than guessing from this article.
What the README does specify is the shape of the setup. There is an "After install (5 minutes)" section and a "First-run security checklist", which implies the app ships with defaults that need changing before exposure. There is also a "Data & backups" section, consistent with the no-database design: your backup target is the data directory plus whatever configuration the app writes.
The manual path is a standard PHP web server. The repository's primary language is JavaScript, which reflects the front end; the backend is PHP. That split matters if you plan to modify it, because a change to permission enforcement will usually touch PHP, while the interface behaviour lives in JavaScript.
Two optional dependencies are named. PDF thumbnails require pdftoppm, and OnlyOffice requires your own Document Server. The API is self-documenting: an OpenAPI spec is served at api.php?spec=1 from openapi.json.dist, with a Redoc UI at api.php behind a login. That is a concrete integration point for anyone scripting against the app.
Where FileRise stops being the right tool
The encryption trade-off is the clearest limitation, and it is self-declared. Enable folder encryption and you lose WebDAV, sharing, ZIP operations and OnlyOffice for those folders. If your workflow depends on mounting the same tree as a network drive, encryption and WebDAV are mutually exclusive in this design. You cannot have both for the same folder.
The absence of a database is the second constraint. It keeps deployment light, but search is described as fuzzy matching over name, tag, uploader and content. The README does not describe an indexed search backend, so on very large trees the search cost is likely proportional to what has to be scanned. The README cites a scale claim of 100k+ folders in the sidebar tree, but that is about rendering the tree, not about query performance, and the two should not be conflated.
The third limitation is the tier boundary. User groups, client portals, automation, gateway shares, audit tooling and the AI workspace are Pro. The MIT core is described as the full open-source feature set, which includes ACLs, sharing, uploads, tags and search, PDF previews, multiple local roots and WebDAV sources. If your requirements list includes groups, you are evaluating a commercial product, not the MIT repository.
Finally, this is not a sync product. There is no desktop client mentioned. WebDAV is the integration path, and the README describes it as a mount, not a synchronisation engine. Anyone expecting conflict resolution across devices should look elsewhere.
Alternatives and the actual difference in approach
Nextcloud is the obvious comparison, and the difference is architectural rather than cosmetic. Nextcloud requires a database and ships a desktop sync client, a calendar, contacts, and an app ecosystem. FileRise has no external database requirement and no sync client in the material provided. If you need two-way desktop sync, Nextcloud is the fit and FileRise is not. If you want a smaller surface with a PHP-only backend and folder-level ACLs that extend to a WebDAV mount, FileRise is the more direct answer.
Seafile is another point of comparison: it is built around block-level synchronisation and a database, which is a different problem statement from a browser-based manager with per-folder permissions. Filebrowser is closer in spirit to FileRise as a lightweight web file manager, but the README's emphasis on granular ACLs enforced across API and WebDAV, plus optional folder-level encryption, describes a permission model that a single-binary file browser does not typically carry.
The honest framing is that FileRise competes on permission granularity and deployment simplicity, not on ecosystem. It does not try to be a groupware suite. That focus is why the encryption mode can afford to disable features: the project treats the encrypted folder as a locked container, and it would rather break WebDAV than serve plaintext over a protocol that cannot participate in the encryption path.
Maintenance, versioning and the licence boundary
The project is active. The most recent release in the supplied data is v3.27.0, dated 2026-08-25, following v3.26.1 and v3.26.0 earlier in the same month. That cadence suggests frequent point releases, which is good for fixes and harder for operators who pin images. If you run this in production, pinning a specific tag and reading the release notes before upgrading is the practical approach, because a change to the ACL enforcement layer touches every surface at once.
The licence is MIT for the core. That permits commercial use, modification and redistribution under the usual terms, and it is the reason the Pro features are a separate offering rather than a licence restriction on the repository. The README has a "License & third-party code" section, which implies bundled dependencies with their own terms. If you redistribute the container, read that section rather than assuming MIT covers everything inside the image. This is a description of the licence, not legal advice.
Upgrade cost is dominated by the encryption feature. If you have encrypted folders, any change to the encryption path is a migration risk, and the README's statement that incompatible features are disabled automatically means the blast radius of an encryption change extends to WebDAV clients and OnlyOffice sessions. Test upgrades in a copy of the data directory before touching the live one. The README's "Data & backups" section is the starting point for that, and the absence of a database means the backup is a directory copy rather than a dump plus files.
The features that decide whether you keep it installed
Beyond permissions, the README lists a set of workflow features that are worth weighing because they determine day-to-day usability. Dual-pane mode with keyboard shortcuts (F3 preview, F4 edit, F5 copy, F6 move, F7 new folder, Del delete, slash for search) is aimed at people who live in a file manager rather than visit it. Hover preview cards show thumbnails, size, timestamps, tags and effective permissions, with a per-user toggle stored in localStorage. The effective-permissions display is a small thing that saves a lot of support time.
File Request links are upload-only: external users submit files into a folder without browsing existing files. That is a genuinely different permission shape from a shared folder, and it is the feature that makes the client-portal use case plausible even in the core. Link File generates authenticated deep links to specific files, requiring login and ACL checks before the target opens.
Tags, fuzzy search and a Trash with time-based retention cover the recovery and organisation basics. Media handling tracks per-file video watch progress and remembers volume and mute state. There is a built-in code editor based on CodeMirror, and internationalisation covering English, Spanish, French, German, Polish, Russian, Japanese and Simplified Chinese according to the README.
The README also carries an "AI Disclosure" section, which is worth reading before you rely on the code for anything security-sensitive. The repository does not state which parts were generated, and that is exactly the kind of thing an operator should check in the source rather than assume either way.
Editorial conclusion
Adopt FileRise if you want a self-hosted file manager where permissions are the product rather than an afterthought, and you accept that the MIT core stops short of groups, client portals and the AI workspace. Do not adopt it if you need a database-backed metadata layer, a sync client, or encrypted folders that still support WebDAV and ZIP operations, because the README states those features are automatically disabled when folder encryption is enabled. Before committing, install the container, create a non-admin user, and verify that a WebDAV mount sees the same permission denials as the web UI; that cross-surface consistency is the claim worth testing first.
Community notes