Web file manager with uploads, tagging, share links, gallery/table views, and an in-browser editor.
License: MIT. Built with: JavaScript, PHP, CSS, HTML, Shell, Dockerfile. Source: https://github.com/error311/FileRise.
```bash docker run -d \ --name filerise \ -p 8080:80 \ -e TIMEZONE="America/New_York" \ -e TOTAL_UPLOAD_SIZE="10G" \ -e SECURE="false" \ -e SCAN_ON_START="true" \ -e CHOWN_ON_START="true" \ -v ~/filerise/uploads:/var/www/uploads \ -v ~/filerise/users:/var/www/users \ -v ~/filerise/metadata:/var/www/metadata \ error311/filerise-docker:latest ``` Then visit: ```text http://your-server-ip:8080 ``` On first launch you’ll be guided through creating the **initial admin user**. > 💡 After the first run, you can set `CHOWN_ON_START="false"` if permissions are already correct and you don’t want a recursive `chown` on uploads/metadata on every start. > > ⚠️ **Uploads folder recommendation** > > It’s strongly recommended to bind `/var/www/uploads` to a **dedicated folder** > (for example `~/filerise/uploads` or `/mnt/user/appdata/FileRise/uploads`), > not the root of a huge media share. > > 🔐 **Persistent tokens key note** > > Keep `/var/www/metadata` persistent. On a pristine install, FileRise writes the > generated persistent tokens key to `metadata/persistent_tokens.key`. If you > choose to manage the key via env instead, keep that value stable for the life > of the instance. > > If you really want FileRise to sit “on top of” an existing share, use a > subfolder (e.g. `/mnt/user/media/filerise_root`) instead of the share root, > so scans and permission changes stay scoped to that folder. ### Option B – docker-compose.yml ```yaml services: filerise: image: error311/filerise-docker:latest container_name: filerise ports: - "8080:80" environment: TIMEZONE: "America/New_York" TOTAL_UPLOAD_SIZE: "10G" SECURE: "false" PERSISTENT_TOKENS_KEY: "${PERSISTENT_TOKENS_KEY:-}" # optional; blank = pristine installs auto-generate and persist a key in metadata SCAN_ON_START: "true" # auto-index existing files on startup CHOWN_ON_START: "true" # fix permissions on uploads/metadata on startup volumes: - ./uploads:/var/www/uploads - ./users:/var/www/users - ./metadata:/var/www/metadata
Self-hosting gives you three things SaaS can’t: data ownership (the files live on disks you control), cost predictability (a one-time setup vs. recurring per-seat fees that grow with your household or team), and longevity (open-source means the app keeps working even if the maintainers move on, since you can pin a working version). The trade-off is that you take on the operational work of running a server, applying updates, and handling backups.
Most self-hosted apps run comfortably on modest hardware — a Raspberry Pi 4, a mini PC, a NAS with Docker support, or a small VPS is usually enough for personal or family use. CPU and RAM requirements scale with how many simultaneous users or how much data you push through FileRise. Storage requirements depend on the kind of data you keep; check the README for guidance on data retention.
Last verified: 2026-04-20