Installation Guide

Overview

RFRNT is distributed as a single binary with no runtime dependencies. It runs its own web server and stores all data—documents, version history, user accounts, and uploaded files—in a single directory you specify. The entire setup process takes about fifteen minutes.

How it works

When you run the RFRNT binary, it starts an HTTP server on the port you specify. All data is stored in a directory you configure via an environment variable. This directory will contain a SQLite database for structured data and an object store for uploaded images and attachments. Back up this directory and you've backed up everything.

First run

On first launch, RFRNT creates an admin user with a randomly generated 32-character alphanumeric password. This password is printed to the console exactly once. Write it down immediately. You'll use it to log in and configure everything else—additional users, document prefixes, and system settings—from within the application itself.

System requirements

Server specifications

RFRNT is lightweight. For teams of up to 25 users, a basic virtual private server is more than sufficient:

• CPU: 1 vCPU
• RAM: 2 GB
• Storage: 50 GB SSD (scales with your document and attachment volume)
• OS: Any Linux distribution with systemd (Ubuntu LTS recommended)

This configuration costs approximately $12–18/month on most cloud providers.

Supported platforms

We provide pre-built binaries for:

• rfrnt-linux-amd64 — Linux on x86_64 (most cloud servers)
• rfrnt-linux-arm64 — Linux on ARM64 (AWS Graviton, Oracle Ampere)

Network requirements

RFRNT needs to communicate with our license server to validate your license. This requires outbound HTTPS access to license.rfrnt.com on port 443. License validation occurs at startup and periodically thereafter, but is cached locally, so brief network interruptions won't affect operation.

License terms

Each license key entitles you to run one instance of RFRNT on exactly one domain. If you need multiple instances, you'll need multiple licenses.

Installation

We recommend DigitalOcean or Vultr for hosting. Both offer simple, affordable virtual private servers with predictable pricing.

Step 1: Create a server

Create a new virtual server with your preferred provider:

1. Choose a region close to your team
2. Select Ubuntu LTS (or any Linux with systemd) as your image
3. Choose a plan that meets or exceeds the system requirements above
4. Add your SSH key for authentication (recommended)
5. Create the server and note its IP address

Step 2: Point your domain

Before installing RFRNT, point your domain to your new server. In your DNS settings, create an A record:

• Type: A
• Name: docs (or your preferred subdomain)
• Value: Your server's IP address

Wait a few minutes for DNS to propagate before continuing.

Step 3: Run the installer

Important: This installer is designed for a dedicated server. It will configure firewall rules, harden SSH, and enable automatic security updates. Do not run it on a server used for other purposes. SSH into your server and run the RFRNT installer:

1. Connect to your server: ssh root@YOUR_SERVER_IP
2. Run the installer: curl -fsSL https://get.rfrnt.com | sh

The installer will:

1. Download the latest RFRNT binary
2. Create a dedicated rfrnt user and data directory
3. Set up a systemd service with automatic restart
4. Prompt you for your license key and domain
5. Configure the firewall (allows only SSH, HTTP, and HTTPS)
6. Enable automatic security updates for the OS
7. Schedule automatic RFRNT updates at 2:00 AM daily
8. Harden SSH configuration
9. Start RFRNT

After installation, your server maintains itself. You don't need to SSH in for updates or maintenance—everything happens automatically.

Step 4: Get your admin password

On first run, RFRNT generates a random password for the admin user. The installer will display it:

Admin password: aB3kL9mNpQ2rStUvWxYz4567890AbCd

Write this down immediately. It's only shown once. You'll use it to log in and configure RFRNT.

Step 5: Access RFRNT

Open your browser and navigate to your domain (e.g. https://docs.yourcompany.com). Log in with username admin and the password from the previous step.

RFRNT handles HTTPS certificate provisioning and renewal automatically. Your domain is saved in the configuration database and is tied to your license key.

Configuration

All RFRNT configuration happens within the application itself. Log in as admin and navigate to Settings in the sidebar.

Environment variables

RFRNT uses the following environment variables. The installer configures these automatically, but you may need to adjust them for custom setups:

Your license key and domain are configured during installation and stored in the database. RFRNT handles HTTPS automatically, obtaining and renewing certificates from Let's Encrypt based on the domain you configure.

Application settings

From Settings → General, you can configure:

• Instance name: The name shown in the header and browser title
• Session duration: How long user sessions remain valid before requiring re-authentication
• Owner publish permission: Whether document owners (not just admins) can publish documents publicly

Document prefixes

From Settings → Prefixes, configure the prefixes used for document reference numbers. Every document in RFRNT gets a permanent reference like DOC-1 or SPEC-42. The prefix determines the category.

Common prefixes include:

Each prefix maintains its own counter. The first document with the SPEC prefix will be SPEC-1, the next SPEC-2, and so on. Numbers are never reused, even if documents are deleted.

Security

RFRNT includes several built-in security measures to protect your data directory from accidental exposure.

Automatic hardening

On startup, RFRNT automatically:

• Refuses to run as root. Running as root is a security risk. Create a dedicated user (the installer does this automatically).
• Secures data directory permissions. The data directory is set to mode 700 (owner read/write/execute only). If RFRNT detects looser permissions, it corrects them and logs a warning.
• Secures sensitive files. The session secret file is set to mode 600 (owner read/write only).

These measures prevent accidental exposure of your data through misconfigured file permissions or reverse proxy settings.

Firewall configuration

On a production server, only ports 80 and 443 should be open to the internet. All other ports should be firewalled. Example using ufw:

ufw default deny incoming
ufw default allow outgoing
ufw allow http
ufw allow https
ufw enable

SSH hardening

Do not expose SSH to the public internet. Port 22 is constantly probed by automated scanners. Even with strong passwords and key-based authentication, an open SSH port increases your attack surface.

If you close SSH entirely, make sure you have an alternative way to access the server in an emergency. Most VPS providers offer a web-based console or out-of-band access—familiarize yourself with it before you need it.

Best practices:

• Close SSH after initial setup. The default firewall configuration above does not allow SSH. Once RFRNT is running, you typically don't need remote shell access.
• Open SSH only when needed. When you need access, open the port temporarily, do your work, then close it again.
• Use a non-standard port. If SSH must remain accessible, use a port other than 22 to avoid the bulk of automated scanning.
• Restrict by IP. Best practice is to allow SSH only from specific IP addresses, a VPN, or an internal network—never the full internet.

Example: temporarily opening SSH on a non-standard port:

# Open SSH on port 2222 for maintenance
ufw allow 2222/tcp
# After you're done, close it
ufw delete allow 2222/tcp

If you use a non-standard port, configure your SSH client accordingly:

ssh -p 2222 user@yourserver.com

What's in the data directory

The data directory contains sensitive information:

• rfrnt.db — SQLite database with all documents, users, and hashed passwords
• session.key — Secret key used to sign session cookies
• objects/ — Uploaded files and attachments
• certs/ — TLS certificates and ACME account keys (auto-managed)

Never expose this directory via your web server or reverse proxy. RFRNT serves only the content it's designed to serve; your data directory should remain inaccessible from the network.

Disk encryption

For additional protection against physical disk theft or cold boot attacks, consider enabling full-disk encryption on your server. Most VPS providers offer this option, or you can configure LUKS manually on Linux.

Backups

All RFRNT data lives in a single directory (the path you specified in RFRNT_DATA_DIR). This directory contains:

• rfrnt.db — SQLite database with all documents, users, and metadata
• objects/ — Uploaded images and attachments

Creating backups

To back up RFRNT, simply copy the entire data directory:

systemctl stop rfrnt
cp -r /var/lib/rfrnt /var/backups/rfrnt-$(date +%Y%m%d)
systemctl start rfrnt

For minimal downtime, you can use SQLite's backup command without stopping the service:

sqlite3 /var/lib/rfrnt/rfrnt.db ".backup /var/backups/rfrnt.db"
cp -r /var/lib/rfrnt/objects /var/backups/rfrnt-objects

Automated backups

DigitalOcean, Vultr, and most VPS providers offer automated server backups for a small additional fee. We highly recommend enabling this feature—it provides point-in-time recovery of your entire server with no configuration required.

Alternatively, you can set up your own backup script. Here's an example cron job that backs up to an S3-compatible object store:

# /etc/cron.daily/rfrnt-backup
#!/bin/bash
BACKUP_DIR="/tmp/rfrnt-backup-$(date +%Y%m%d)"
mkdir -p $BACKUP_DIR
sqlite3 /var/lib/rfrnt/rfrnt.db ".backup $BACKUP_DIR/rfrnt.db"
cp -r /var/lib/rfrnt/objects $BACKUP_DIR/objects
tar -czf $BACKUP_DIR.tar.gz -C /tmp $(basename $BACKUP_DIR)
aws s3 cp $BACKUP_DIR.tar.gz s3://your-backup-bucket/rfrnt/
rm -rf $BACKUP_DIR $BACKUP_DIR.tar.gz

Restoring from backup

To restore from a backup:

systemctl stop rfrnt
rm -rf /var/lib/rfrnt/*
cp -r /var/backups/rfrnt-20250101/* /var/lib/rfrnt/
systemctl start rfrnt

Updating

RFRNT updates itself automatically. Every day at 2:00 AM (server local time), your server checks for updates and installs them if available. The service restarts automatically with zero downtime for your users.

You don't need to do anything. Updates just happen.

Manual updates

If you want to update immediately instead of waiting for the next automatic update:

rfrnt-update

This runs the same update process that happens automatically each night.

Update logs

To see what updates have been applied:

cat /var/log/rfrnt-update.log

How updates work

The updater downloads the latest binary, compares it to the currently installed version, and only restarts the service if there's actually a change. Database migrations run automatically on startup, so your data is always preserved.

Troubleshooting

Viewing logs

RFRNT logs to stdout, which systemd captures. View recent logs with:

journalctl -u rfrnt -f

The -f flag follows the log in real-time. Remove it to see historical logs.

Certificate issues

If you see TLS or certificate errors:

• DNS not pointing to server: Ensure your domain's A record points to your server's IP address. Let's Encrypt validates domain ownership before issuing certificates.
• Port 443 blocked: Ensure port 443 is open in your firewall and not used by another service.
• Rate limited: Let's Encrypt has rate limits (5 duplicate certificates per week). If you're testing, set RFRNT_ACME_STAGING=true to use their staging environment.
• First-start delay: On first run, certificate acquisition may take 30-60 seconds. This is normal.

Certificate files are stored in /var/lib/rfrnt/certs/ and are automatically renewed before expiry.

License issues

If you see license validation errors:

• Verify RFRNT_LICENSE_KEY is set correctly in your service file
• Ensure your server can reach license.rfrnt.com on port 443
• Check that your license hasn't expired—licenses are valid for one year from purchase
• Verify the domain in your license matches your configured RFRNT_DOMAIN

License validation occurs at startup and periodically (every 6 hours) to ensure continued validity. If the license server is temporarily unreachable, RFRNT continues operating with the cached license status.

Permission issues

If RFRNT can't write to the data directory, ensure the rfrnt user owns it:

chown -R rfrnt:rfrnt /var/lib/rfrnt
chmod 700 /var/lib/rfrnt

RFRNT will refuse to start if run as root. If you see "RFRNT should not run as root", ensure your systemd service runs as the rfrnt user (the installer configures this automatically).

Port conflicts

If ports 80 or 443 are already in use by another service, you have two options:

• Use a reverse proxy: Set RFRNT_TLS_ENABLED=false and configure nginx or Caddy to proxy to RFRNT on a different port.
• Change ports: Set RFRNT_PORT and RFRNT_HTTPS_PORT to available ports.

After changing the service file:

systemctl daemon-reload
systemctl restart rfrnt

Getting help

If you're stuck, email . Include your RFRNT version (shown at the bottom of the Settings page) and any relevant log output.