RSSHub

Last reviewed Aug 26, 2026 · 903 words

The public RSSHub instance at rsshub.app is the wrong way to use RSSHub, and that single fact is why the project is worth self-hosting. Shared instances get rate-limited or outright blocked by the sites they scrape, so the route that works for you today returns a 503 tomorrow because 10,000 other people hit the same origin from the same IP. Your own copy uses your own IP, holds your own API keys, and costs about 256 MB of RAM in a container that has run on my box for years without attention.

It makes feeds; it does not read them

RSSHub is a feed generator, not a reader. Every route is a URL pattern that RSSHub fetches on demand, scrapes, and returns as RSS, Atom, or JSON Feed. http://rsshub:1200/github/issue/DIYgod/RSSHub gives you the issue tracker for the RSSHub repo itself; /telegram/channel/durov gives you a public Telegram channel. There are hundreds of route families covering thousands of sources, and the route documentation at docs.rsshub.app lists every parameter each one takes.

You still need something to subscribe to those URLs. FreshRSS or Miniflux on the same Docker network is the usual pairing; the FreshRSS vs Miniflux comparison covers which one to pick. Point the reader at http://rsshub:1200/... over the internal network and RSSHub never needs a public port at all.

The compose file, with the two extras that matter

services:
  rsshub:
    image: diygod/rsshub:latest
    environment:
      - CACHE_TYPE=redis
      - REDIS_URL=redis://redis:6379/
      - PUPPETEER_WS_ENDPOINT=ws://browserless:3000
      - ACCESS_KEY=change-me-to-something-long
    depends_on:
      - redis
      - browserless
    restart: unless-stopped
  redis:
    image: redis:alpine
    restart: unless-stopped
  browserless:
    image: browserless/chrome
    restart: unless-stopped

Redis is the first extra. RSSHub caches every route's output (the default CACHE_EXPIRE is 300 seconds), and with in-memory caching the cache dies on restart and cannot be shared. Redis makes the cache persistent and lets a reader polling 200 feeds every 15 minutes hit the origin sites far less often, which is also what keeps your IP from being the next one blocked.

Browserless is the second. A minority of routes need a real browser because the target site renders with JavaScript; RSSHub drives one through Puppeteer over the websocket endpoint above. Skip it and those routes fail with an unhelpful error; include it and budget another 500 MB to 1 GB of RAM for Chrome.

ACCESS_KEY matters even on a LAN. Without it, anyone who can reach port 1200 can make your server scrape arbitrary sites on their behalf. With it, every request needs ?key=your-key appended, which your reader handles fine as part of the feed URL.

Some routes need keys, and some will simply break

The honest part of the catalogue's cons list is "some routes break over time", and it is true. RSSHub works by scraping, and the sites being scraped do not care about your feed. The pattern I have seen over several years: routes for sites with stable public APIs (GitHub, Telegram, most podcast hosts, government and university sites) stay working for years; routes for sites that actively fight scraping (anything owned by Meta, X/Twitter, several e-commerce platforms) break every few months and get fixed by community contributors a few weeks later.

Routes with official APIs want credentials in the environment. GITHUB_ACCESS_TOKEN lifts GitHub's anonymous rate limit from 60 to 5,000 requests per hour; YOUTUBE_KEY is required for most YouTube routes; Twitter routes need account cookies and are the most fragile in the catalogue. Read a route's page in the docs before subscribing; if it lists a required config variable, set it first and save yourself a debugging session.

Finding routes without reading the catalogue

The RSSHub Radar browser extension (Chrome and Firefox) is the trick that makes this practical. Visit any site, click the icon, and it lists every RSSHub route that matches the page, plus any native feed the site already publishes. Set your own instance's URL in its options and the routes it offers point straight at your server. Between Radar and the docs search, I have never had to read route source code to figure out a URL.

Update it more often than you think

Because routes are patched constantly, a six-month-old RSSHub image is missing dozens of fixes. I pull the image weekly with an automated updater and have never had a breaking change in the container itself; the environment-variable configuration has been stable for years. The container updates without fires post covers the pattern. If a feed goes quiet, check the docs page for the route before assuming your setup is at fault; the changelog will usually tell you it broke upstream.

What I'd do

Run RSSHub next to your reader on the same Docker network, no public port, ACCESS_KEY set, Redis for cache, browserless only if a route you actually want needs it. Set GITHUB_ACCESS_TOKEN on day one. Subscribe to stable-API sources freely and treat scraped social-media routes as a nice-to-have that will need re-checking. Done that way it is the cheapest, most useful 256 MB in an RSS stack, and it is the piece that turned "this site has no feed" from a dead end into a two-minute job.