Miniflux and FreshRSS: The Case for Running Your Own Reader

Two readers, one argument about who owns your data

Self-hosting a feed reader used to be a fringe position, the kind of infrastructure decision that invited blank stares at dinner parties. After the Google Reader shutdown on 1 July 2013, it became a principled one. If a company managing tens of millions of subscriptions could walk away from the product with three months' notice, the argument for running your own reader acquired a weight it had previously lacked. Miniflux and FreshRSS are the two tools that emerged from that period as the serious self-hosted alternatives, and a decade on they remain the dominant choices for anyone unwilling to hand their reading infrastructure to a third party.

The difference between them is less about features than about design philosophy. Miniflux is written in Go, ships as a single binary, and has made minimalism a non-negotiable constraint. Its developer, Frédéric Guillot, has consistently refused feature requests that would compromise that constraint. The interface is spare to the point of austerity: no tagging hierarchies, no folder nesting beyond a flat category, no visual clutter. What it offers instead is speed, a clean REST API, and a Fever-compatible endpoint that lets users plug in third-party mobile clients. The entire application — web interface, feed fetcher, background scheduler — runs in one process against a PostgreSQL database. Deployment on a VPS takes minutes rather than hours.

FreshRSS occupies the opposite end of the self-hosted spectrum. It is a PHP application that has accumulated, over more than a decade of community development, a feature set that genuinely rivals hosted services. It supports custom CSS injection, per-feed scraping rules for publishers who serve truncated content, OPML import and export, multiple user accounts, and a statistics dashboard that tracks reading habits over time. Its API layer implements both the Google Reader protocol and the Fever API, meaning nearly every third-party client built for the post-Reader diaspora can connect to it. Where Miniflux says no, FreshRSS almost always says yes — and that breadth is both its strength and the source of its occasional instability under edge-case configurations.

What running your own reader actually costs

The honest accounting of self-hosting starts with time, not money. A small VPS from any reputable provider — the kind sufficient to run either application comfortably — costs somewhere between three and eight dollars a month, depending on region and provider. Miniflux's Go binary imposes negligible resource overhead; a 512 MB instance handles several hundred subscriptions without strain. FreshRSS, running under PHP-FPM with a MySQL or PostgreSQL backend, benefits from at least 1 GB of RAM as subscription counts grow, but it remains well within the capacity of a cheap virtual machine.

The less visible cost is the maintenance cadence. Both projects release updates regularly — Miniflux through tagged releases on its GitHub repository, FreshRSS likewise through a maintained release branch. Security patches require attention. Database backups require a cron job or equivalent. Neither application is usually exposed directly; TLS is typically handled by a reverse proxy such as nginx or Caddy. None of these tasks are technically demanding, but each represents a decision point that a hosted service absorbs invisibly. Users who have not run a Linux server before will encounter a learning curve that the pricing comparison does not capture.

What self-hosting returns against those costs is data that stays under the reader's own control: the complete history of every article fetched, every item marked read, every subscription ever added. Neither Miniflux nor FreshRSS phones home, monetises reading behaviour, or imposes a subscription cap. When Feedly and Inoreader adjust their pricing tiers — and both have, repeatedly — the self-hosted reader is unaffected. When a hosted service is acquired or shut down, the OPML export lands in a directory the user already controls rather than in an email with a deadline attached.

A feed is a text file sitting on a server. Between the publisher and the reader there is a fetch, and nothing else.Photo: Tima Miroshnichenko / Pexels

The WebSub protocol, which allows publishers to push updates to subscribers rather than waiting to be polled, is supported by FreshRSS natively; Miniflux can be configured to receive push notifications from hubs as well, reducing latency for high-frequency feeds. Both readers implement conditional GET — the HTTP caching mechanism using ETag and Last-Modified headers — which means they avoid re-downloading feeds that have not changed, a courtesy to small publishers running on shared hosting.

The case for self-hosting a feed reader is not that it is easier than using Feedly. It is not. The case is that ownership and continuity are worth the marginal complexity — and that in the eleven years since Google Reader closed, the tools available to make that argument practical have only improved.