RSS feeds never went away. Most blogs, news sites, forums, and even a lot of YouTube channels and subreddits still publish one, whether or not they advertise it on the page. What disappeared was the easy on-ramp, Google Reader shut down over a decade ago and nothing free and centralized ever fully replaced it as the default. The gap got filled by a handful of paid hosted services (Feedly, Inoreader) and by self-hosting, and for a homelab operator the self-hosted path has a real advantage beyond just avoiding a subscription: your reading list, read/unread state, and starred articles stay on hardware you control, not in a third party’s analytics pipeline. FreshRSS, Miniflux, and Tiny Tiny RSS (TT-RSS) are the three tools that consistently come up, and they land in genuinely different places on the simplicity-versus-features spectrum.
What an RSS reader is actually doing
At its core, an RSS reader is a polling job plus a database plus a web UI. It fetches each subscribed feed on a schedule (every 15-60 minutes is typical), diffs the new entries against what it’s already seen, stores the new ones, and presents them through a web interface or an API that a mobile app can talk to. None of that is resource-intensive compared to most self-hosted services, a few hundred feeds polling on a reasonable interval is a trivial load for anything that can also run Pi-hole or Uptime Kuma. The real differentiators are the UI itself, how content extraction and full-text fetching work for feeds that only publish a summary, and which mobile app ecosystem each one plugs into.
FreshRSS: the easiest first deploy
FreshRSS is the one most people land on first, and for good reason. It’s a single PHP application with a well-documented Docker image, a clean web UI that works fine on mobile browsers without a dedicated app, and a setup wizard that gets you from zero to reading feeds in a few minutes. It supports OPML import for migrating a feed list from Feedly or wherever else you’re coming from, has built-in full-text extraction for feeds that only ship a teaser, and exposes both the Fever API and the Google Reader API, which is what lets third-party mobile apps (Reeder, FocusReader, several others) talk to it without FreshRSS needing to ship its own app.
Where it’s lighter than the other two: there’s no real multi-user administration story built for teams, categorization and filtering rules are functional but basic compared to TT-RSS, and it doesn’t do as much native content enrichment out of the box. For a single person or a household running one instance with a few accounts, none of that matters. It’s the right default unless you have a specific reason to want more.
Miniflux: minimalist by design, and it means it
Miniflux is a single static Go binary with a Postgres backend, and that architectural choice runs all the way through the product. The UI is deliberately spare: no themes, no reading-mode customization rabbit hole, no plugin system, just a fast, clean reading list that gets out of the way. It supports the Fever API and its own Miniflux API for mobile client compatibility, OPML import/export, and full-content fetching via built-in scraping rules for feeds that only publish summaries.
The philosophy is explicit in Miniflux’s own documentation: fewer features, done well, rather than a sprawling feature list. That’s a real selling point if you’ve been burned by a self-hosted tool that accumulated UI cruft over years of feature requests, Miniflux has stayed disciplined about saying no. The cost is that if you specifically want granular filtering rules, per-feed scraping rule customization beyond the built-in defaults, or multi-user team administration, you’ll hit the ceiling faster than with TT-RSS. For most individual users that ceiling is never actually reached.
Tiny Tiny RSS: the deepest feature set, and the most to manage
TT-RSS has been around the longest of the three and it shows in the feature list: a full plugin architecture, powerful filter rules (route feeds into folders, auto-mark-as-read based on keyword matches, strip content you don’t want), a native Android app, and a more traditional three-pane desktop reading layout that some long-time RSS users specifically prefer over the single-column list the other two use. It also runs its own dedicated update daemon process separate from the web application, which is more moving parts than a FreshRSS or Miniflux deploy but gives more control over polling behavior and scheduling.
That extra capability comes with real setup and maintenance overhead. The Docker Compose deployment has more components (web app, database, update daemon, often a separate scheduler container depending on the compose file you use), configuration lives across more files, and the project’s documentation, while thorough, assumes more comfort with self-hosted PHP/web-app stacks than the other two options do. If you’re the kind of homelab operator who wants filter rules and plugins and is willing to spend an evening getting the daemon wired up correctly, it’s worth it. If you just want feeds to show up and be readable, it’s more tool than you need.
Mobile access: check your actual app before picking
This is the detail that should drive the decision for a lot of people, more than any feature comparison on paper. All three expose the Fever API (a de facto standard originally from the long-dead Fever app) and/or the Google Reader API, which is what most third-party RSS mobile apps actually speak. Before committing to one, check whether your preferred mobile app (Reeder, Unread, FocusReader, NetNewsWire, whatever you already use or want to use) lists compatibility with that specific backend, compatibility claims vary by app version and aren’t universal across all three. TT-RSS additionally ships its own dedicated Android app if you don’t already have a preferred third-party client and don’t want to shop for one.
Where to run it
All three fit comfortably in a small LXC or a Docker Compose stack alongside your other self-hosted apps, nothing here needs meaningful CPU or RAM even with a large feed list. Put it behind your existing reverse proxy with a real TLS certificate (see the reverse proxy comparison on this site if you haven’t settled on one yet) since you’ll likely want to reach it from your phone outside your home network, and that means authentication actually matters here even though “it’s just a feed reader” makes it tempting to skip. Back up the database the same way you back up every other self-hosted app’s data, your subscription list and years of read/unread/starred state is exactly the kind of thing that’s annoying to lose and easy to forget isn’t being backed up until it’s gone.
Bottom line
FreshRSS is the right starting point for almost everyone, easy to deploy, good mobile app compatibility, full-text extraction built in, and no feature gap you’re likely to actually hit as a single user or small household. Miniflux is the pick if deliberate minimalism appeals to you and you want the smallest possible thing that reliably does the job, a single binary and a database, nothing else to reason about. TT-RSS is the pick if you specifically want filter rules, a plugin ecosystem, or a native Android app and you’re fine spending more time on initial setup and ongoing maintenance to get them. Any of the three gets your reading habits off a hosted service’s servers and onto hardware you control, which is the actual point.