FileRise 3.38.0 on AWS User Guide

Overview

This guide covers launching and using the FileRise 3.38.0 on Ubuntu 24.04 AMI from cloudimg on Amazon EC2. It is one version of the cloudimg file sharing and sync listing on AWS Marketplace; you pick it as the software version when you subscribe and launch.

FileRise is an open source, self hosted web file manager. In the browser your team can upload files (drag and drop, large files in resumable chunks), create folders, move, copy and rename files, tag and search them, edit text files inline, download several files as one zip, extract archives, share a file or folder with a link (optionally password protected and with an expiry), and restore deleted files from the Recycle Bin. An administrator adds users and decides, folder by folder, who may see, upload, edit or share what. There is no database to run: files live on the file system and users, permissions and metadata in small files next to them.

The cloudimg image locks FileRise down:

• No default administrator and no open setup page. Upstream FileRise lets the first visitor create the administrator. This image ships no user store at all and does not serve the site until first boot has created the admin account with a password unique to your instance (stored as a bcrypt hash), closed the first run setup and written the password to /root/filerise-credentials.txt (root only).
• HTTPS from the first boot. nginx serves FileRise on port 443 with a certificate generated on your instance's first boot. Port 80 redirects to HTTPS, and requests for a host name the instance does not serve are dropped.
• Brute force protection. After five failed sign ins, further attempts from that address are refused for a while, and the sign in routes are rate limited. The session cookie is Secure, HttpOnly and SameSite=Lax, and a new session id is issued at every sign in.
• Uploads can never run. Your files live on a dedicated data volume (mounted noexec), outside the web server's document root, and are only ever returned through FileRise's signed in download. PHP files, scripts and hidden dot files are refused as upload, folder, rename and save names, and archive extraction cannot write outside its folder.
• Cross site requests are refused. FileRise's API refuses a call that does not come from FileRise's own page, and every change additionally needs FileRise's per session token, so another website cannot make your browser download, delete or change files. Share links keep working when you send them to someone.
• No FileRise Pro code. This is the MIT licensed FileRise. The routes that would download and install the commercial Pro bundle or bind a licence with filerise.net are switched off, and the folder Pro would load code from is owned by root and empty.
• Metadata service blocked. nginx, PHP and the first boot step that creates your administrator cannot reach the EC2 instance metadata service, so a request crafted to make FileRise fetch a URL cannot read the instance's role credentials.
• Fully patched Ubuntu 24.04 LTS at build time, PHP 8.3 with the latest security fixes, and unattended security upgrades switched on.

What is on the image: FileRise 3.38.0 (MIT; the project's own release build, verified against the v3.38.0 source tag), with its bundled DOMPurify updated to 3.4.17, PHP 8.3 (FPM), nginx, Ubuntu 24.04 LTS, cloud-init and the AWS Systems Manager agent. The licence and exact sources are in /usr/share/doc/filerise/.

Default user: ubuntu · Architecture: x86_64 · Recommended instance type: m5.large

Prerequisites

• An AWS account subscribed to the listing, an EC2 key pair and a VPC subnet.
• A security group that allows TCP 22 (SSH), TCP 443 (FileRise) and TCP 80 (redirects to HTTPS) from your own networks only.

Step 1: Launch the instance

In the AWS Marketplace listing choose Continue to Subscribe, then Continue to Configuration, pick FileRise 3.38.0 on Ubuntu 24.04 as the software version and your Region, then Launch through EC2. Choose m5.large, your key pair, a security group as above, and a subnet. The AMI brings an 8 GiB root volume and a separate 20 GiB data volume that holds your files; raise the data volume under Configure storage if you need more space (you can also grow it later, see Step 9).

With the AWS CLI (replace the values in angle brackets; this sets the data volume to 100 GiB):

aws ec2 run-instances --region <region> --image-id <ami-id-from-the-listing> \
  --instance-type m5.large --key-name <your-key-pair> \
  --security-group-ids <your-security-group> --subnet-id <your-subnet> \
  --metadata-options HttpTokens=required,HttpEndpoint=enabled \
  --block-device-mappings 'DeviceName=/dev/sdf,Ebs={VolumeSize=100,VolumeType=gp3}' \
  --tag-specifications 'ResourceType=instance,Tags=[{Key=Name,Value=filerise}]'

Step 2: Connect to your instance

ssh -i <your-key.pem> ubuntu@<public-ip>

Step 3: Check the services

First boot generates the certificate, creates the administrator and starts the site. It takes a few seconds:

systemctl is-active filerise-host filerise-firstboot php8.3-fpm nginx

active
active
active
active

Only SSH (22) and nginx (80, 443) listen on the network; PHP talks to nginx over a local socket, and the two loopback entries are Ubuntu's local DNS resolver:

sudo ss -lntp | awk 'NR>1 {print $4}' | sort -u

0.0.0.0:22
0.0.0.0:443
0.0.0.0:80
127.0.0.53%lo:53
127.0.0.54:53
[::]:22
[::]:443
[::]:80

The health helper checks that the site, PHP and the data volume answer:

sudo /usr/local/sbin/filerise-health

PRIMARY_HEALTH_OK https://ec2-203-0-113-10.compute-1.amazonaws.com/ (healthz 200, page 200, site config JSON)

If nginx is not running, first boot has not finished (or failed, in which case the site is never served). Check systemctl status filerise-host filerise-firstboot and journalctl -u filerise-firstboot.

Step 4: Get your URL and password

sudo cat /root/filerise-credentials.txt

The file is readable by root only and holds the address and this instance's administrator sign in:

# FileRise 3.38.0 - generated on first boot by filerise-firstboot.service
# This password is unique to this instance; none was baked into the image. Keep this file secret.

FILERISE_URL=https://ec2-203-0-113-10.compute-1.amazonaws.com/
FILERISE_ADMIN_USER=admin
FILERISE_ADMIN_PASSWORD=<FILERISE_ADMIN_PASSWORD>
...

You can confirm the sign in from the instance itself. The helper checks the redirect, that an anonymous visitor cannot list files, that the first run setup is closed, that a wrong password and common defaults are refused, and that the password signs in through FileRise's own login and lists your files:

sudo /usr/local/sbin/filerise-cred-roundtrip

OK https 301 + anonymous refused + setup closed + wrong/default passwords refused + admin signs in and lists the root folder

Step 5: Sign in

Open the FILERISE_URL address in your browser. The certificate is self signed until you install your own (Step 8), so the browser asks you to accept it once; compare the fingerprint it shows with the one on the instance:

sudo openssl x509 -in /etc/nginx/ssl/filerise.crt -noout -fingerprint -sha256

Sign in as admin with the password from Step 4. A new instance always shows the sign in page, never a setup form:

FileRise opens on your (empty) root folder, with the upload area and the folder tree on the left and the file list on the right:

Change the administrator password to one of your own whenever you like: in FileRise open the User Panel and change it there, or on the instance (16 to 128 characters, no spaces; the helper reads it from standard input, so it never appears in your shell history or the process list, and updates the credentials file):

sudo filerise-set-password --stdin

Run sudo filerise-set-password without --stdin to generate a new random password instead. Sessions signed in with the old password are signed out; other users are not touched.

Step 6: Manage files, users and sharing

Drag files or a whole folder onto the Upload Files/Folders area (or click Choose files); New creates folders and files. Select files to move, copy, rename, tag, download as a zip or delete them; deleted files go to the Recycle Bin in the folder tree, where an administrator can restore them. Text files open in the built in editor, and Share creates a link for a file or folder that you can protect with a password and an expiry.

As admin, open the Admin Panel from the user menu (top right) and use Users & Access to add users and choose, folder by folder, what each user may view, upload, edit, delete or share. Users see only the folders they have been given:

Things to know:

• Refused names. PHP files (.php, .phtml, .phar and similar), shell and other script files, .htaccess / .user.ini files and names that start with a dot are refused when you upload, create, rename or save. Every other type uploads normally.
• Direct links. A FileRise download link pasted into a new browser tab's address bar is refused (it carries no proof that it came from FileRise's page); use the download action, or a share link, instead.
• WebDAV is off until an administrator enables it in the Admin Panel (Auth & WebDAV); it then answers at https://<your-host>/webdav.php/ with the FileRise user's name and password.
• FileRise Pro features (the sections marked PRO in the Admin Panel, and the Pro licence and bundle install) are not available on this image.

Step 7: Where your files live

Your files are in /var/lib/filerise/uploads on the data volume, owned by the unprivileged filerise account that PHP runs as. Users, passwords (bcrypt hashes) and folder permissions are in /var/lib/filerise/users, and tags, share links and FileRise's per instance token key in /var/lib/filerise/metadata, all readable only by filerise:

sudo ls -la /var/lib/filerise

total 40
drwxr-xr-x  7 root     root      4096 Oct 30 19:15 .
drwxr-xr-x 50 root     root      4096 Oct 30 19:04 ..
drwx------  2 root     root     16384 Oct 30 19:04 lost+found
drwxr-x---  2 filerise filerise  4096 Oct 30 19:38 metadata
drwx------  2 filerise filerise  4096 Oct 30 19:05 tmp
drwxr-x---  2 filerise filerise  4096 Oct 30 19:05 uploads
drwx------  2 filerise filerise  4096 Oct 30 19:38 users

To copy files in over SSH, write them as that account so FileRise can manage them, for example:

sudo -u filerise cp /home/ubuntu/report.pdf /var/lib/filerise/uploads/

Step 8: Use your own host name and certificate

Point a DNS record at the instance (an Elastic IP keeps the address across stop and start), then tell the instance its name. This mints a new self signed certificate for that name, updates the nginx host rule, the cross site guard and the address in the credentials file, and keeps the name across reboots:

sudo filerise-set-hostname files.example.com

To use a certificate from a public authority instead, replace /etc/nginx/ssl/filerise.crt (full chain) and /etc/nginx/ssl/filerise.key (mode 0600, owned by root) with your own and run sudo systemctl reload nginx. Running filerise-set-hostname again later would replace them with a new self signed pair.

Step 9: Check persistence, storage and updates

Every service is enabled, so FileRise returns after a reboot or a stop and start; your files, users and passwords stay as they are. Unattended security upgrades keep the operating system, PHP and nginx patched:

systemctl is-enabled nginx php8.3-fpm unattended-upgrades

enabled
enabled
enabled

The data volume is mounted by its file system UUID. To grow it, enlarge the EBS volume in the EC2 console and then extend the file system online:

sudo resize2fs $(findmnt -no SOURCE /var/lib/filerise)

To back up your files, users and share links, take an EBS snapshot of the data volume (or use AWS Backup on the instance). cloudimg publishes a new version of the image when a newer FileRise release is available.

Security notes

• No shared secret ships in the image. No user store, password, password hash, token key, TLS key or credentials file exists until your instance's first boot generates them, and nginx refuses to start until that has finished.
• Fail closed. If first boot cannot complete, nothing is served, and FileRise's first run setup can never be reached from the network.
• PHP is confined. It runs as the filerise account, can write only FileRise's data folders, is limited to FileRise's own folders (open_basedir), and has system, passthru, proc_open and popen disabled (FileRise keeps only what it needs to start its PHP zip worker); FileRise's code is owned by root and read only to it. Sessions are kept in memory, never on disk.
• Metadata service blocked. nginx, PHP (including the zip worker it starts) and the first boot step that creates your administrator are blocked from the EC2 instance metadata service; only the step that looks up the instance's public name uses it (IMDSv2).
• Security fixes. FileRise 3.38.0 includes the fixes for every published FileRise advisory (all fixed in 3.37.0 or earlier). Its bundled copy of DOMPurify 3.4.2 had published advisories, though FileRise never called the affected functions; this image replaces it with DOMPurify 3.4.17. PHP is Ubuntu's PHP 8.3 with the fixes for CVE-2026-109618 and CVE-2026-109619.
• Restrict 22/tcp to your management network, and 80/443 to the networks that use FileRise.

Architecture summary

Support

cloudimg images come with 24/7 support. Email support@cloudimg.co.uk with your AWS account ID and the instance ID. For FileRise itself, see the FileRise project on GitHub.

FileRise is an open source project by error311 and contributors. cloudimg is not affiliated with or endorsed by the FileRise project.