FreshRSS vs Miniflux

Last reviewed Aug 24, 2026 · 543 words

Both are excellent, mature, actively maintained answers to "Feedly, but mine" — and they embody opposite philosophies so cleanly that most people know their pick within five minutes of using each. Miniflux is opinionated minimalism: a fast list of unread items, a reader view, keyboard-driven, nothing to theme and little to configure, because its author believes a feed reader should disappear. FreshRSS is configurable pluralism: multi-user, extension ecosystem, custom CSS themes, per-feed filtering and refresh rules, reading statistics. Neither philosophy is wrong; they're for different readers.

What daily use feels like

Miniflux gives you chronological unread entries, j/k navigation, a scraper that fetches full article content for truncated feeds, and integrations to push articles onward (Wallabag, Readwise, Shiori and friends). Its refusal to grow features is the feature — the interface hasn't meaningfully changed in years, which its users consider a promise kept. FreshRSS reads more like a traditional aggregator (think the old Google Reader, deliberately): folders, tags, favourites, a normal/reader/global view switch, and power-user machinery Miniflux refuses on principle — per-feed CSS selectors for full-content retrieval, search filters you can save, automatic labelling rules. If your subscriptions number in the hundreds and need active curation, FreshRSS's tooling earns its complexity; the case for RSS in 2026 is really the case for readers like these.

Deployment and footprint

Miniflux is a single Go binary that requires PostgreSQL — its one operational opinion, non-negotiable — and idles around 128 MB total. FreshRSS is PHP with SQLite by default (MariaDB/Postgres optional), which makes its minimal install actually the simpler one: one container, one volume. The classic FreshRSS trap is feeds that never refresh — set CRON_MIN in the container environment or nothing updates on its own. Both are trivial loads for any Pi-class box; this decision carries no hardware weight.

The mobile story is a tie, deliberately

Neither ships a first-party mobile app; both instead implement the compatibility APIs the ecosystem standardised on — Google Reader API and Fever — so clients like Reeder, NetNewsWire, ReadYou, and Fluent Reader work against either server. In practice the phone experience is whatever client you like, identical for both. FreshRSS's multi-user support is the differentiator that isn't a tie: a family or small community sharing one instance, each with their own subscriptions, is a FreshRSS feature with no Miniflux equivalent (Miniflux has users, but FreshRSS is built around the shared-instance case with admin tooling to match).

Decision table

What I'd do

Try Miniflux first — its constraint is clarifying, and if it fits, you're done thinking about feed readers permanently. Move to FreshRSS if you notice yourself wanting rules, themes, or a second user within the first month; the OPML export/import between them takes five minutes, so the cost of guessing wrong is a coffee break. Either way you end up with the correct outcome: your reading queue on your hardware, no algorithm deciding what you see.