Self-hosted RSS and feed readers in 2026: revisit FreshRSS, Miniflux and Tiny Tiny RSS before you follow another feed through an algorithm

Most engineers follow a lot of sources: release notes of the databases they run, security advisories, vendor status pages, a few good engineering blogs and maybe a newsletter or two. Today much of this reaches us through social feeds and recommendation engines. The algorithm decides what we see, in what order, and what we never see at all. An important advisory can sit below ten trending posts.

RSS and Atom solve this in a boring and reliable way. A site publishes a feed, your reader fetches it, and you see every item in time order. Nothing is ranked for engagement. The only question is where the reader runs and who holds your subscription list and reading history.

In 2026 three open source, self-hosted readers deserve a calm look: FreshRSS, a feature rich multi-user PHP aggregator; Miniflux, a minimalist Go application that works only with PostgreSQL; and Tiny Tiny RSS (tt-rss), the long running PHP reader that changed hands in 2025.

The revisit habit stays the same. Learn what each tool stores and how it fetches. Unlearn the idea that a timeline is a neutral view of the world. Re-learn how feeds, polling and sync APIs work. Practise an OPML export and a database restore. Then apply it to the sources your team really depends on.

A scenario to keep us honest

This is an invented scenario, not a real company. Indore Uptime Works is a five person team that runs managed PostgreSQL and Kubernetes for a handful of small clients. Every day someone has to notice new releases of PostgreSQL, Kubernetes, ingress controllers and backup tools, plus CERT-In and vendor security advisories. Today this depends on whoever happens to scroll social media that morning. The team lead wants:

  • One shared list of must-follow sources, so a new joiner gets the same view on day one
  • Reading on phones as well as laptops, with read state kept in sync
  • Something that one person can upgrade and back up in under an hour a month

We will come back to this team at the end.

Where these tools came from

FreshRSS

The FreshRSS GitHub repository was created in October 2012. The project describes itself as a self-hosted RSS feed aggregator that is lightweight, easy to work with, powerful and customisable, translated into many languages. Its README says it is a multi-user application with an anonymous reading mode, an API for mobile clients and a command line interface. At the time of writing, the latest release on GitHub is 1.30.4, published on 22 October 2026 (IST).

Miniflux

Miniflux 2 lives in the miniflux/v2 repository, created in November 2017. The project calls itself “a minimalist and opinionated feed reader” and credits Frederic Guillot as its developer. The website puts it plainly: no fancy features, less is more. The latest release on GitHub at the time of writing is 2.3.5, published on 2 November 2026 (IST).

Tiny Tiny RSS

Tiny Tiny RSS was created by Andrew Dolgov, known as “fox”, and has a history of roughly two decades. In early October 2025 he announced that on 1 November 2025 he would dismantle the infrastructure behind tt-rss.org, including its Git repositories and forum. His stated reason was that he no longer found it fun to maintain public facing projects, and that tt-rss had been “done” for years.

The software did not stop there. The current README at github.com/tt-rss/tt-rss says the original project was retired on 2025-11-01, and that this repository is a fork as of 2025-10-03, created by a long time contributor (wn_ on tt-rss.org, supahgreg on GitHub). The stated goals are to continue development with no major breaking changes planned, keep the minimum PHP version in line with Debian stable, and publish Docker images for amd64 and arm64 as drop-in replacements for the old images. Documentation from tt-rss.org was recreated in a new repository, and plugins were mirrored to GitHub. In an early discussion on the fork, the maintainer noted that features which talked to the old tt-rss.org, such as update checks and plugin installation, were disabled at first.

The honest summary: tt-rss is maintained, but by a new and small team, after a founder handover. That is a governance fact to weigh, not a reason to panic.

Licences, in plain words

FreshRSS

FreshRSS is licensed under the GNU AGPL 3. You can use, change and self-host it freely. If you modify it and offer it to others over a network, you must share your modified source with those users.

Miniflux

Miniflux uses the permissive Apache 2.0 licence. You can use, modify and embed it with very few obligations beyond keeping notices.

Tiny Tiny RSS

Tiny Tiny RSS is licensed under the GNU GPLv3. For a team that only runs it internally, the practical obligations are small. Redistribution of modified versions requires sharing source.

For all three, there is no paid enterprise edition hiding important features. What you see in the repository is the product.

How each is built

FreshRSS

  • PHP application, PHP 8.2 or newer according to the README
  • Runs behind Apache 2.4 (recommended), nginx or lighttpd
  • Database: PostgreSQL 10+, SQLite, MariaDB 10.6+ or MySQL 8.0+
  • The README says it even works on a Raspberry Pi 1, tested with 150 feeds and 22k articles; treat that as the project’s own observation, not a benchmark
  • Official Docker image, plus a command line interface for admin tasks

Miniflux

  • Go application, compiled statically without external dependencies according to the website
  • Works only with PostgreSQL; full-text search uses PostgreSQL
  • Distributed as a single binary, RPM and Debian packages, or a Docker image
  • Follows the Twelve-Factor App methodology, so configuration comes from environment variables

Tiny Tiny RSS

  • PHP application, now officially recommended to run with Docker; the site says support may be limited without it
  • The published images are a PHP-FPM application image and a separate nginx web image, and the original image name made the PostgreSQL pairing explicit
  • Continuous development model: the main branch and the latest Docker image are considered stable, and staying current is strongly encouraged

In short, Miniflux has the fewest moving parts if you already run PostgreSQL. FreshRSS is the most flexible about databases and can start small on SQLite. tt-rss expects a Docker and PostgreSQL setup.

Features that matter for a small team

FreshRSS

  • Multi-user, with an optional anonymous reading mode
  • Login by web form, HTTP authentication (works with a reverse proxy doing auth) or OpenID Connect
  • WebSub support, so compatible sources can push new items instantly instead of waiting for polling
  • Basic web scraping with XPath, and JSON documents, for sites that do not publish a feed
  • Resharing selections of articles as HTML, RSS or OPML through user queries
  • Extensions for further customisation

Miniflux

  • Atom, RSS and JSON Feed formats, OPML import and export
  • Categories, bookmarks, public sharing of single articles, full-text search
  • Fetches the original article and extracts content with a local Readability parser, plus custom scraper rules
  • Saves articles to third party services
  • Local username and password, passkeys (WebAuthn) and generic OpenID Connect
  • Interface available in 20 languages, including Hindi

Tiny Tiny RSS

  • Folders and subfolders, OPML import and export, keyboard shortcuts
  • Flexible article filtering, which long time users value for noisy feeds
  • Full article content through readability and site-specific plugins
  • Deduplication, including perceptual hashing for images
  • Podcasts, plugins and themes, and sharing through generated RSS feeds or URLs
  • Its own JSON API

Sync APIs and mobile apps

Most people do not want to read only in a browser. The reader on your server becomes a sync backend, and a mobile or desktop app talks to it through an API.

  • FreshRSS supports two APIs: the Google Reader API, which its README calls the best option, and the Fever API, which it describes as limited, less efficient and less safe. The README keeps a long list of compatible apps.
  • Miniflux offers compatibility with existing mobile apps through the Fever or Google Reader API, and its own REST API with client libraries in Go and Python.
  • Tiny Tiny RSS has its own JSON API. Apps need to speak that API specifically.

Practical advice: pick your mobile app first, check which API it uses, then confirm that API on the reader you choose. Prefer the Google Reader API over Fever when both exist, as FreshRSS itself suggests.

Privacy: the reader can also protect you

A feed item is HTML from someone else’s server. It can carry tracking pixels and tracked links. Miniflux is explicit here. Its README lists removal of pixel trackers, stripping of tracking parameters such as utm_source and fbclid, a media proxy, a no-referrer policy, blocking of external JavaScript, content sanitising and a strict Content Security Policy. Miniflux also says there is no telemetry or advertising. For FreshRSS and tt-rss, check their documentation and extensions for similar behaviour before you assume it.

Operations

Installation

  • FreshRSS: Docker image, or a classic PHP install on a web server; SQLite is fine for a small pilot
  • Miniflux: one binary or a container, plus a PostgreSQL database
  • tt-rss: Docker Compose with the app image, the nginx image and PostgreSQL; users of the old images were told they could switch image names to the fork’s images

Upgrades

  • FreshRSS offers a rolling edge branch and a slower latest branch. For a team, follow tagged releases and read release notes.
  • Miniflux publishes regular tagged releases. Pin a version in your Compose file or package manager and move forward deliberately.
  • tt-rss asks users to stay on the latest main or latest image. Pin to a specific image tag anyway, so you know exactly what you run, and update often.
  • For all three, take a database backup immediately before each upgrade.

Monitoring

Watch three simple things: the container or service is up, feeds are actually being refreshed (a stuck updater is a common silent failure), and disk usage of the database is not growing without limit. Configure article retention so old items are purged.

Backups

A feed reader holds less precious data than a document store, but losing subscriptions, starred items and filters still hurts.

  • Export OPML regularly from each user account; it is the portable list of subscriptions and works across all three tools
  • Back up the database with the native tool: pg_dump for PostgreSQL, a consistent copy for SQLite, mysqldump or mariadb-dump for MySQL and MariaDB
  • Back up configuration: environment files, Compose files, FreshRSS data directory, tt-rss plugins and themes
  • Keep one copy off the server and restore it once on a spare machine before you trust it

Security

Exposure

Put the reader behind HTTPS with a reverse proxy. If only the team uses it, consider keeping it on a VPN or behind single sign on. FreshRSS supports HTTP authentication by proxy and OpenID Connect; Miniflux supports OpenID Connect and passkeys.

The fetcher is a server-side request maker

Every feed reader fetches URLs that users type in. That means a user can ask your server to reach internal addresses. Limit the outbound network of the container where possible, keep it away from admin interfaces and cloud metadata endpoints, and give only trusted people accounts.

API credentials

Mobile apps store API credentials. Use separate API passwords where the tool supports them, avoid the Fever API when a better option exists, and revoke access when someone leaves.

Supply chain for tt-rss

After the 2025 handover, make sure your Compose file points to the fork’s images (supahgreg/tt-rss on Docker Hub or ghcr.io/tt-rss/tt-rss) and not to old, unmaintained images. Old images will not receive PHP or security fixes.

The Indian context: the DPDP Act

A feed reader mostly stores public content, but it also stores user accounts, email addresses and reading history. Under the Digital Personal Data Protection Act, 2023, that is personal data of your employees or users. Keep it on infrastructure you control, collect only what you need, set a retention period for old articles and logs, and delete an account properly when a person leaves. If you offer the reader to clients or the public, treat it as a service that processes personal data and document it. This is general guidance, not legal advice.

When not to adopt each

Do not choose FreshRSS if

  • You want the smallest possible footprint and no PHP stack at all
  • You dislike a wide feature surface and many settings

Do not choose Miniflux if

  • You cannot or will not run PostgreSQL
  • You want rich plugins, complex filters or heavy customisation; the project is opinionated by design

Do not choose Tiny Tiny RSS if

  • Your governance policy needs a larger maintainer group; the fork is young and small
  • You do not run Docker, since non-Docker setups may get limited support
  • Your preferred mobile app does not speak the tt-rss API

Do not self-host at all if

  • Nobody will own monthly upgrades and backups; an unpatched public web app is worse than a hosted reader

Back to Indore Uptime Works

For this invented team, a sensible path is to pilot Miniflux, because they already run PostgreSQL every day, the single binary is easy to upgrade, and the Google Reader API lets everyone use a mobile app of their choice. They create one shared account category for must-follow sources (database releases, Kubernetes releases, CERT-In and vendor advisories) and export it as OPML for new joiners. If later they want a guest read-only view for clients or scraping of sites without feeds, a short FreshRSS trial is worth doing. A team member already happy with tt-rss can keep it, but should move to the fork’s images. No hands-on drill was run for this article; the plan is based on the projects’ own documentation.

Revisit checklist

  • List the sources your team must not miss, and get their feed URLs
  • Choose the mobile app first, then confirm its API on the reader
  • Check the database the reader needs and whether you already run it
  • Pin versions and read release notes before each upgrade
  • Export OPML and back up the database, and keep one copy off site
  • Restrict the fetcher’s network access and keep the app behind HTTPS
  • For tt-rss, confirm you are on the maintained fork’s images
  • Map accounts and reading history to DPDP retention and deletion
  • Practise a restore before you trust it

Sources

comments powered by Disqus

Releted Posts

Self-hosted bookmarks and read-later in 2026: revisit Linkwarden, Karakeep and Wallabag before you save another link to Pocket

Every technical team collects links. A design document refers to a vendor page. A support engineer saves the forum thread that finally fixed a customer issue.

Read more

Self-hosted photo libraries in 2026: revisit Immich, PhotoPrism and Ente before you upload another album to Google Photos

Photos look like a personal topic, but in many small Indian businesses they are working data. A studio keeps client shoots.

Read more

Self-hosted document management in 2026: revisit Paperless-ngx, Mayan EDMS and Docspell before you scan another invoice into a shared drive

Every small business has a paper problem that slowly becomes a file problem. Purchase invoices, GST returns, rent agreements, salary slips, vendor KYC, insurance policies, bank statements.

Read more