FreshRSS

What it is

• FreshRSS is a web-based feed reader for following blogs, release notes and project updates in one place.
• It is useful when you want a quiet reading workflow instead of depending on many site-specific dashboards.

When it is a good fit

• You follow engineering blogs, changelogs and upstream release feeds regularly.
• You want a browser-based reader that is simple to host and easy to update.
• You prefer starting with SQLite before adding another database service.

When it is not the best choice

• You need heavy multi-user workflows with strict role separation.
• You want a knowledge base rather than a feed reader.

Minimum VPS requirements

• 1 vCPU is fine for personal or small shared use.
• 1 GB RAM is typically enough.
• Disk usage depends more on retention and feed count than on the app itself.

Starter install

• FreshRSS can be installed in several ways, but for a small VPS I would start with the official container and let the web installer create a SQLite-backed setup.
• The FreshRSS documentation also keeps repeating one useful rule that is easy to miss: the data directory is the important state, and in a manual install only the public app folder should be exposed to the web server.

services:
  freshrss:
    image: freshrss/freshrss:latest
    restart: unless-stopped
    ports:
      - "127.0.0.1:8081:80"
    environment:
      TZ: Europe/Amsterdam
      CRON_MIN: "13,43"
    volumes:
      - ./data:/var/www/FreshRSS/data
      - ./extensions:/var/www/FreshRSS/extensions

• Start the container with `docker compose up -d` and open the installer through nginx.
• For a personal or very small shared setup, pick SQLite first. It keeps the deployment short and matches the way many people begin with FreshRSS.
• Import a few feeds, wait for the built-in refresh cycle to run, and then confirm that new entries appear before spending time on extra extensions.
• If you ever move away from the container image and run FreshRSS directly behind a web server, expose only the public application folder and keep the data directory outside that document root.

Deployment notes

• Start with SQLite unless you already maintain MariaDB for other services.
• Use a named volume for data and extensions so image replacement stays easy.
• Feed refresh intervals should match how often you actually read updates.

Reverse proxy / nginx notes

• Serve FreshRSS behind nginx with a single hostname and explicit client body limits.
• Keep upstream buffering defaults unless you have a measured reason to change them.
• Use standard forwarded headers so the application detects the external scheme correctly.

Data, volumes and backups

• Back up the data directory first because it contains the reader state and local configuration.
• If you use MariaDB, include regular database dumps or volume snapshots in the same schedule.
• A copied `.env` file and Compose definition make restoration much faster.

Updates and maintenance

• Trim unused extensions and old feeds occasionally to keep troubleshooting simple.
• Update on a regular schedule instead of letting several major releases pile up.
• After upgrades, spot-check feed refresh and login flow.

Common pitfalls

• Large feed lists with short refresh intervals create unnecessary background work.
• Changing database backends later is possible, but it is still migration work you can avoid early.
• File permissions can get messy if volumes are moved between hosts without planning.

Alternatives

• Miniflux for an even leaner reading setup.
• Tiny Tiny RSS if you need a different extension model.

Official links

For installation details, release information and current support policy, always check the official project resources directly.

• Official site
• Source code