Miniflux vs Tiny Tiny RSS: RSS Readers Compared

Two Different Philosophies

Miniflux and Tiny Tiny RSS both solve the same problem — self-hosted feed reading — but they approach it from opposite directions.

Updated March 2026: Verified with latest Docker images and configurations.

Miniflux is built around subtraction. It’s a single Go binary that does feed reading and nothing else. No plugins, no themes, no extension system. The developer actively refuses feature requests that don’t serve the core reading experience. The result is an app that starts in milliseconds, uses 30 MB of RAM, and gets out of your way.

Tiny Tiny RSS (TT-RSS) is built around addition. It’s a PHP application with a plugin architecture, theme system, and a traditional three-pane layout modeled after desktop RSS readers like Thunderbird. It aims to be a full-featured feed reader that can be customized and extended to fit any workflow.

This isn’t a case of one app being “better.” It’s two fundamentally different answers to how software should work. Miniflux says: do less, do it perfectly. TT-RSS says: do everything, let the user configure what they need.

Quick Verdict

Miniflux is the better choice for most self-hosters. It’s dramatically lighter on resources, has a superior API ecosystem for mobile app integration, and the focused UI makes reading faster. Choose TT-RSS if you specifically want plugin extensibility, a traditional three-pane layout, or you need feature-level customization that Miniflux deliberately doesn’t offer.

Feature Comparison

Feature	Miniflux	Tiny Tiny RSS
Language	Go (single binary)	PHP (FPM + Nginx)
Database	PostgreSQL (required)	PostgreSQL (required)
Multi-user	Yes	Yes
Plugin system	No (by design)	Yes (extensive)
Theme support	Dark/light toggle only	Multiple themes + custom CSS
Google Reader API	Yes (native)	No
Fever API	Yes (native)	Yes (via plugin)
REST API	Full REST API	JSON API
Full-text fetch	Built-in readability parser	Via af_readability plugin
Keyboard shortcuts	Extensive, Vim-style	Yes
OAuth/OIDC	Built-in OIDC support	No native support
Feed autodiscovery	Yes	Yes
OPML import/export	Yes	Yes
Content filters	Regex-based filtering rules	Plugin-based filtering
Saved searches	No	Yes (via virtual feeds)
Labels/tags	Categories only	Labels + categories
Feed icons (favicons)	Yes	Yes
Sharing integrations	20+ (Pinboard, Wallabag, Telegram, Matrix, etc.)	Via plugins (Share, Pocket, etc.)
Docker image count	1 container + PostgreSQL	3 containers + PostgreSQL
Docker image size	~20 MB	~200 MB (combined)
RAM usage (idle)	~30 MB	~150-250 MB

Docker Setup

Miniflux

Miniflux needs two containers: the app itself and PostgreSQL.

Create a docker-compose.yml:

services:
  miniflux:
    image: miniflux/miniflux:2.2.18
    container_name: miniflux
    depends_on:
      db:
        condition: service_healthy
    ports:
      - "8080:8080"
    environment:
      # PostgreSQL connection string
      DATABASE_URL: postgres://miniflux:CHANGE_THIS_PASSWORD@db/miniflux?sslmode=disable
      # Run database migrations on startup
      RUN_MIGRATIONS: 1
      # Create admin user on first start (remove after initial setup)
      CREATE_ADMIN: 1
      ADMIN_USERNAME: admin
      ADMIN_PASSWORD: CHANGE_THIS_ADMIN_PASSWORD
    restart: unless-stopped
    networks:
      - miniflux-net

  db:
    image: postgres:17-alpine
    container_name: miniflux-db
    environment:
      POSTGRES_USER: miniflux
      POSTGRES_PASSWORD: CHANGE_THIS_PASSWORD
      POSTGRES_DB: miniflux
    volumes:
      - miniflux-db:/var/lib/postgresql/data
    healthcheck:
      test: ["CMD", "pg_isready", "-U", "miniflux"]
      interval: 10s
      timeout: 5s
      retries: 5
    restart: unless-stopped
    networks:
      - miniflux-net

volumes:
  miniflux-db:

networks:
  miniflux-net:

Start it:

docker compose up -d

Access the web UI at http://your-server:8080. Log in with the admin credentials you set. After the first login, remove CREATE_ADMIN, ADMIN_USERNAME, and ADMIN_PASSWORD from the environment variables — they’re only needed once.

Tiny Tiny RSS

TT-RSS uses a multi-container architecture: a PHP-FPM app server, a feed updater daemon, an Nginx web server, and PostgreSQL.

Create a .env file:

# Database credentials — change these
TTRSS_DB_USER=ttrss
TTRSS_DB_NAME=ttrss
TTRSS_DB_PASS=CHANGE_THIS_PASSWORD

# Web server binding — adjust for your setup
HTTP_PORT=127.0.0.1:8280

# Admin password for first login — change this
ADMIN_USER_PASS=CHANGE_THIS_ADMIN_PASSWORD

Create a docker-compose.yml:

services:
  db:
    image: postgres:17-alpine
    container_name: ttrss-db
    environment:
      POSTGRES_USER: ${TTRSS_DB_USER}
      POSTGRES_PASSWORD: ${TTRSS_DB_PASS}
      POSTGRES_DB: ${TTRSS_DB_NAME}
    volumes:
      - ttrss-db:/var/lib/postgresql/data
    healthcheck:
      test: ["CMD", "pg_isready", "-U", "${TTRSS_DB_USER}"]
      interval: 10s
      timeout: 5s
      retries: 5
    restart: unless-stopped
    networks:
      - ttrss-net

  app:
    image: ghcr.io/tt-rss/tt-rss:20260216-144157
    container_name: ttrss-app
    depends_on:
      db:
        condition: service_healthy
    environment:
      TTRSS_DB_HOST: db
      TTRSS_DB_USER: ${TTRSS_DB_USER}
      TTRSS_DB_NAME: ${TTRSS_DB_NAME}
      TTRSS_DB_PASS: ${TTRSS_DB_PASS}
      TTRSS_DB_PORT: 5432
      # Set this to your public URL
      TTRSS_SELF_URL_PATH: http://localhost:8280/tt-rss
      ADMIN_USER_PASS: ${ADMIN_USER_PASS}
    volumes:
      - ttrss-app:/opt/tt-rss
    restart: unless-stopped
    networks:
      - ttrss-net

  updater:
    image: ghcr.io/tt-rss/tt-rss:20260216-144157
    container_name: ttrss-updater
    depends_on:
      - app
    environment:
      TTRSS_DB_HOST: db
      TTRSS_DB_USER: ${TTRSS_DB_USER}
      TTRSS_DB_NAME: ${TTRSS_DB_NAME}
      TTRSS_DB_PASS: ${TTRSS_DB_PASS}
      TTRSS_DB_PORT: 5432
      TTRSS_SELF_URL_PATH: http://localhost:8280/tt-rss
    volumes:
      - ttrss-app:/opt/tt-rss
    command: /opt/tt-rss/updater.sh
    restart: unless-stopped
    networks:
      - ttrss-net

  web-nginx:
    image: ghcr.io/tt-rss/tt-rss-web-nginx:20260216-144157
    container_name: ttrss-web
    depends_on:
      - app
    ports:
      - "${HTTP_PORT}:80"
    volumes:
      - ttrss-app:/opt/tt-rss
    restart: unless-stopped
    networks:
      - ttrss-net

volumes:
  ttrss-db:
  ttrss-app:

networks:
  ttrss-net:

Start it:

docker compose up -d

Access TT-RSS at http://your-server:8280/tt-rss. Log in with username admin and the password you set in ADMIN_USER_PASS. Update TTRSS_SELF_URL_PATH to match your actual domain if you’re using a reverse proxy.

The difference in deployment complexity is immediately visible. Miniflux is two containers. TT-RSS is four. This isn’t inherently bad — TT-RSS separates concerns cleanly — but it does mean more moving parts to monitor and maintain.

Performance and Resource Usage

This is where the architectural difference hits hardest.

Miniflux is a statically compiled Go binary. It starts in under a second, serves pages instantly, and idles at roughly 30 MB of RAM. With 500+ feeds and a single user, total stack memory (Miniflux + PostgreSQL) stays under 150 MB. CPU usage during feed refreshes is negligible.

TT-RSS runs PHP-FPM behind Nginx. The stack idles at 150-250 MB of RAM across its four containers. Page loads are noticeably slower — not unusably slow, but the difference is perceptible when switching between the two. Feed updates consume more CPU due to PHP’s execution model. With hundreds of feeds, expect occasional spikes.

Metric	Miniflux	Tiny Tiny RSS
Containers required	2	4
RAM (idle, full stack)	~100 MB	~300 MB
RAM (under load)	~150 MB	~500 MB
Startup time	< 1 second	10-15 seconds
Feed refresh CPU	Minimal	Moderate
Disk (images + data)	~50 MB + DB	~250 MB + DB

For a Raspberry Pi or a small VPS, Miniflux is the clear winner. TT-RSS runs fine on any machine with 1 GB+ of RAM, but it won’t feel as snappy.

API and Mobile Apps

Miniflux has the strongest API story of any self-hosted RSS reader. It offers three APIs simultaneously:

• Native REST API — full CRUD for feeds, categories, entries, users. Well-documented, consistent, and used by several third-party clients.
• Google Reader API — compatible with apps like Reeder, lire, and News+.
• Fever API — compatible with apps like Unread and ReadKit.

This means virtually every RSS mobile app on iOS and Android can connect to Miniflux natively.

TT-RSS has its own JSON-based API that powers the official Android app. Fever API support is available through a plugin. There is no Google Reader API compatibility. This limits mobile client options — you’re largely confined to the official TT-RSS Android app (no iOS equivalent) or Fever-compatible clients.

If mobile reading is part of your workflow, Miniflux has a significant advantage.

Community and Development

Miniflux is maintained by a single developer (Frédéric Guillot) and has been actively developed since 2013. The project is hosted on GitHub, accepts contributions, and has a responsive issue tracker. The codebase is small and readable. Documentation is thorough and well-organized. Development pace is steady — multiple releases per year with security fixes and incremental improvements.

Tiny Tiny RSS has a longer history (started around 2005) and a more complex community dynamic. The project moved to a community-maintained fork on GitHub in late 2025 under the tt-rss organization. It has an active plugin ecosystem with dozens of community-contributed plugins. The codebase is significantly larger (PHP + JavaScript). Documentation exists but is less polished than Miniflux’s.

Aspect	Miniflux	Tiny Tiny RSS
First release	2013	~2005
Primary language	Go	PHP
GitHub stars	~7,000+	~9,000+
Plugin ecosystem	None (intentional)	Dozens of plugins
Theme ecosystem	None (dark/light only)	Community themes
Documentation	Excellent	Adequate
Release model	Versioned releases	Rolling (date-tagged builds)

Use Cases

Choose Miniflux If…

• You want the fastest, lightest RSS reader possible
• You read feeds on mobile using apps like Reeder, lire, or News+
• You prefer a keyboard-driven, distraction-free reading experience
• You run on limited hardware (Raspberry Pi, small VPS, shared hosting)
• You want a clean REST API for automation or custom integrations
• You value simplicity in deployment and maintenance (two containers, done)
• You use OAuth/OIDC for authentication

Choose Tiny Tiny RSS If…

• You want a traditional three-pane RSS reader layout (folders, feeds, articles)
• You need plugin extensibility (custom filters, sharing targets, feed processors)
• You want to customize the UI with themes and CSS
• You need virtual feeds and saved searches for complex feed organization
• You prefer a label-based organization system alongside categories
• You want to self-host something that feels like a full desktop application in the browser
• You have plenty of server resources and don’t mind the extra containers

Final Verdict

Miniflux is the better RSS reader for most self-hosters. It’s faster to deploy, dramatically lighter on resources, and its triple-API support means you can use whatever mobile client you prefer. The deliberately minimal UI sounds like a limitation until you use it — it turns out that removing clutter makes you read more and fidget less.

TT-RSS is the right choice if you specifically need what Miniflux doesn’t offer: plugins, themes, saved searches, and a traditional RSS client layout. It’s a capable application with a long track record. But if you’re starting fresh and don’t have a specific TT-RSS feature in mind, start with Miniflux. You can always migrate later — both support OPML export.

For a third option that splits the difference between the two, check out FreshRSS — it offers extensions and themes like TT-RSS but with lighter resource usage.

Related

• How to Self-Host Tiny Tiny RSS with Docker
• How to Self-Host Miniflux
• How to Self-Host FreshRSS
• FreshRSS vs Miniflux
• Best Self-Hosted RSS Readers
• Self-Hosted Alternatives to Feedly
• Docker Compose Basics
• Reverse Proxy Setup