Subscribe

RSS in 2026: Why I Still Use Miniflux and How It Feeds My Dashboard

RSS is the only technology that reliably delivers the content I chose, without an algorithm deciding what I should see. Miniflux on Kubernetes feeds my reading into a personal analytics dashboard.

RSS in 2026: Why I Still Use Miniflux and How It Feeds My Dashboard

I have used RSS for over a decade. When Google Reader died in 2013, I moved to Feedly. When Feedly started pushing AI features and premium tiers, I moved to Miniflux. Running my own RSS reader on Kubernetes is the end of that migration chain: there is no service to shut down, no pricing to change, no algorithm to insert between me and the content I chose to follow.

Why RSS Still Matters

Every major content platform optimizes for engagement, not for the reader. Twitter's algorithm shows you rage bait because it drives clicks. YouTube's recommendations spiral into increasingly extreme content. LinkedIn surfaces sponsored posts disguised as organic. The common thread: someone else decides what you see, and their incentives don't align with yours.

RSS is the antidote. You subscribe to feeds. You see every post from those feeds, in chronological order. Nothing is hidden, nothing is promoted, nothing is algorithmically amplified. The content you see is exactly the content you chose.

In 2026, this feels almost radical. It shouldn't be. It's how the web was designed to work.

Why Miniflux

There are dozens of self-hosted RSS readers: Tiny Tiny RSS, FreshRSS, NewsBlur, Stringer, Yarr. I chose Miniflux for specific reasons:

  • Minimal by design. Miniflux does one thing: fetch feeds and display articles. No social features, no bookmarking system, no "AI summary" nonsense. The UI is fast, clean, and keyboard-navigable.
  • PostgreSQL backend. Most RSS readers use SQLite, which is fine until you have thousands of articles and want fast full-text search. Miniflux uses PostgreSQL, which handles the query patterns (filtered lists, full-text search, bulk mark-as-read) more naturally.
  • Native OIDC support. Miniflux has first-class OAuth2/OIDC integration. Point it at Authentik's discovery URL, provide a client ID and secret, and it auto-creates users on first login. No ForwardAuth needed.
  • Excellent API. Miniflux exposes a clean REST API with token authentication. Every operation available in the UI is available via API. This makes the Life Hub collector integration straightforward.
  • Single binary. Miniflux is a Go binary with no runtime dependencies beyond PostgreSQL. The container image is small, startup is fast, and resource usage is minimal.

The Kubernetes Deployment

Miniflux requires PostgreSQL, so it's a two-container deployment in my cluster:

# PostgreSQL for Miniflux
containers:
- name: postgres
  image: postgres:16-alpine
  env:
  - name: POSTGRES_DB
    value: miniflux
  - name: POSTGRES_USER
    value: miniflux
  - name: POSTGRES_PASSWORD
    valueFrom:
      secretKeyRef:
        name: miniflux-secrets
        key: db-password
  volumeMounts:
  - name: db-data
    mountPath: /var/lib/postgresql/data

# Miniflux
- name: miniflux
  image: miniflux/miniflux:2.2.5
  env:
  - name: DATABASE_URL
    value: postgres://miniflux:$(DB_PASSWORD)@localhost/miniflux?sslmode=disable
  - name: RUN_MIGRATIONS
    value: "1"
  - name: CREATE_ADMIN
    value: "1"
  - name: OAUTH2_PROVIDER
    value: oidc
  - name: OAUTH2_OIDC_DISCOVERY_URL
    value: https://auth.naviauxlab.com/application/o/miniflux/.well-known/openid-configuration
  - name: OAUTH2_CLIENT_ID
    valueFrom:
      secretKeyRef:
        name: miniflux-oidc
        key: client-id
  - name: OAUTH2_CLIENT_SECRET
    valueFrom:
      secretKeyRef:
        name: miniflux-oidc
        key: client-secret
  - name: OAUTH2_REDIRECT_URL
    value: https://miniflux.naviauxlab.com/oauth2/oidc/callback
  - name: OAUTH2_USER_CREATION
    value: "1"

Both containers run in the same pod: PostgreSQL is only accessed locally via localhost. This simplifies networking (no Service needed for the database) and ensures they're always co-located on the same node.

Resource usage is light: Miniflux typically uses 30-50 MB of RAM. PostgreSQL uses 50-100 MB depending on how many articles are cached. Combined, it's one of the lighter workloads in the cluster.

What I Follow

About 60 feeds across a few categories:

  • Technology: Hacker News (top stories), Ars Technica, The Pragmatic Engineer, Julia Evans, Oxide Computer blog
  • Kubernetes/DevOps: Kubernetes blog, CNCF blog, Flux CD releases, Cilium blog, Longhorn releases
  • Security: Krebs on Security, Schneier on Security, SANS ISC, NIST CVE feed
  • Homelab: r/selfhosted (RSS feed from Reddit), r/homelab, various homelab bloggers
  • Personal interests: Brain Pickings, Wait But Why, Stratechery, a few cooking blogs

I read about 15-25 articles per day. Miniflux's "mark all as read" shortcut prevents inbox anxiety: if I fall behind, I can declare bankruptcy on a category without guilt.

The Reading Stats Collector

Life Hub's Miniflux collector runs every 15 minutes as part of the collector CronJob. It fetches the 50 most recently read articles:

class MinifluxCollector(BaseCollector):
    name = "miniflux"

    async def collect(self) -> list[dict[str, Any]]:
        if not settings.MINIFLUX_URL or not settings.MINIFLUX_API_KEY:
            return []

        url = f"{settings.MINIFLUX_URL}/v1/entries"
        params = {
            "status": "read",
            "order": "changed_at",
            "direction": "desc",
            "limit": 50,
        }
        headers = {"X-Auth-Token": settings.MINIFLUX_API_KEY}

        async with httpx.AsyncClient(timeout=30.0) as client:
            resp = await client.get(url, params=params, headers=headers)
            entries = resp.json().get("entries", [])

        records = []
        for entry in entries:
            records.append({
                "source": "miniflux",
                "category": "reading",
                "event_type": "article_read",
                "title": entry.get("title", ""),
                "timestamp": entry.get("published_at") or entry.get("changed_at"),
                "metadata": {
                    "url": entry.get("url"),
                    "feed_title": (entry.get("feed") or {}).get("title"),
                    "author": entry.get("author"),
                    "reading_time": entry.get("reading_time"),
                },
            })
        return records

Each article becomes an ActivityEvent with metadata for the URL, feed title, author, and estimated reading time. These appear on the Life Hub timeline alongside music listening, code commits, and other activity.

The MCP tool get_reading_stats() exposes reading data to Claude, returning article counts and recent titles. When I ask "what have I been reading this week?", the answer comes from real data, not memory.

How RSS Feeds the Dashboard

Reading activity integrates with Life Hub's analytics in several ways:

  • Timeline: Articles appear chronologically alongside other activity. I can see that I read three Kubernetes articles, then listened to an audiobook, then pushed two commits: a visible narrative of how I spent my time.
  • Daily digest: The reading count appears in the daily summary. "You read 12 articles today" gives context to how the day was spent.
  • Correlation engine: Life Hub can correlate reading volume with other metrics. Do I read more on days with higher mood scores? Do I read less when I sleep poorly? The data exists to answer these questions.
  • Council of Advisors: The AI advisory system sees reading activity in its briefings. An advisor might note "your reading has dropped to 3 articles/day this week, down from your usual 15", a signal that something has changed.

RSS vs. Algorithmic Feeds

I still use Twitter (or whatever it's called now) and Reddit. But I use them differently than RSS. Social media is for discovery: finding new voices, following breaking conversations, seeing what the community is excited about. RSS is for depth: following specific writers and projects over time.

The distinction matters because it changes what I read. Social media surfaces the most engaging content, which often means the most provocative or the most viral. RSS surfaces everything from the sources I chose, which means the quiet, thoughtful, carefully-researched posts that would never trend on any algorithm.

Some of the best technical writing I've read came from personal blogs with a few hundred subscribers. These posts would never surface on Hacker News or Twitter: they're too niche, too specific, too long. But they're exactly what I want in my feed reader, and RSS is the only technology that delivers them reliably.

Miniflux and Linkding: The Read-It-Later Stack

Miniflux integrates with Linkding (my self-hosted bookmark manager) as a read-it-later system. When I find an article in Miniflux that I want to save or reference later, I bookmark it in Linkding. The workflow:

  1. Discover article in Miniflux feed
  2. Save to Linkding via browser extension or Miniflux integration
  3. Linkding stores the bookmark with full-text content, tags, and archive
  4. Life Hub's Miniflux collector captures the read event for analytics

This replaces Pocket, Instapaper, and similar services. The entire read-it-later pipeline is self-hosted, and the data flows into my personal analytics system automatically.

The Cost of Self-Hosting RSS

Miniflux uses maybe 80 MB of RAM total (app + PostgreSQL). At my cluster's power draw, that's a fraction of a cent per day. The SaaS equivalent (Feedbin at $5/month or Feedly Pro at $6/month) costs more in a month than Miniflux costs in electricity for a year.

The setup cost was about an hour: write the Kubernetes manifests, configure OIDC in Authentik, import my OPML file from Feedly. One-time investment, zero ongoing cost.

Lessons

RSS is infrastructure, not a product. Email survived because it's an open protocol that anyone can implement. RSS has the same quality. It doesn't depend on a company staying in business or maintaining a compatible API. An RSS feed published in 2005 still works in 2026. No social media platform can say the same.

Curate aggressively. The temptation with RSS is to subscribe to everything. Resist it. A feed reader with 200 unread articles creates the same anxiety as a cluttered email inbox. I prune feeds quarterly: if I'm consistently skipping a feed, I unsubscribe.

Reading metrics change behavior. Since Life Hub started tracking my reading, I've become more intentional about it. Seeing "you read 3 articles today" when my average is 15 makes me notice that I spent the day in meetings instead of learning. The metric isn't a goal. It's awareness.

Self-hosted RSS is the gateway drug. Miniflux was one of my first self-hosted services. The experience of running it (controlling my data, customizing the interface, integrating it with other tools) is what convinced me to self-host everything else. If you're considering self-hosting, start here. RSS is simple enough to deploy in an hour and useful enough to make the effort worthwhile from day one.