# RSSHub has no GitHub release, a 1.0.0 version, and 5,000 self-hosted copies

> RSSHub turns routes into RSS feeds and ships as a Node service, a set of Cloudflare and Vercel build targets, a container image and a small library export, all under AGPL-3.0. The README is a pointer document with a sponsor table in it, the real instructions live on docs.rsshub.app, and the npm version number tells you nothing about the code in the container.

**DIYgod/RSSHub** — RSSHub generates RSS feeds from almost any source — from YouTube and Telegram to Weibo and Bilibili — through a large self-hostable route network.

- Repository: https://github.com/DIYgod/RSSHub
- Website: https://docs.rsshub.app
- Stars: 46,325 · Forks: 10,241
- Language: TypeScript
- License: AGPL-3.0
- Published: 2026-08-08 · Updated: 2026-08-18 · Language: en
- Canonical page: https://hysenlabs.com/projects/diygod-rsshub

## No GitHub release, so the 1.0.0 in package.json means nothing

The repository publishes no GitHub releases. That single fact changes how you should pin this project. The root package.json still carries a version field, and it reads 1.0.0, which is the number the npm package and any tag-based tooling will see. It is not a signal about the code you are running: the last push to master was on 2026-09-25, and the build scripts in the same file describe a service with Playwright workers, container images and worker bundles. The README's own scale claim is that RSSHub is a network of over 5,000 global instances delivering millions of aggregated items, which is a claim about self-hosted deployments rather than about a release train. Practical consequence: identify a deployment by the Docker tag or by a commit, and treat any semver comparison against the npm package as meaningless. The service on rsshub.app is the third option, and it is the one the README links first.

## Port 1200, Redis, and a headless browser you either comment out or keep

The compose file is where the real deployment shape shows, three services with two of them optional. The application block reads:

```yaml
        image: diygod/rsshub # or ghcr.io/diygod/rsshub
        restart: always
        ports:
            - '1200:1200'
        environment:
            NODE_ENV: production
            CACHE_TYPE: redis
            REDIS_URL: 'redis://redis:6379/'
            PLAYWRIGHT_WS_ENDPOINT: 'ws://browserless:3000' # marked
```

The comment convention in that file is the part to understand before editing anything. Lines marked # marked belong to the browserless service and its endpoint. The file's own comment gives the two choices: comment out the marked lines and switch to the diygod/rsshub:chromium-bundled image, or leave everything unchanged and accept the extra disk and memory. So Playwright support is not a setting, it is a topology decision. Redis is not optional in this file, since CACHE_TYPE is set to redis, and its own healthcheck uses redis-cli ping against a named volume.

## One healthcheck endpoint, thirty second interval, three retries

The service is watched through a single HTTP probe, and the numbers are the ones to copy if you write your own orchestration:

```yaml
        healthcheck:
            test: ['CMD', 'curl', '-f', 'http://localhost:1200/healthz']
            interval: 30s
            timeout: 10s
            retries: 3
```

A GET against /healthz on the published port is the whole contract. Two things follow. The port is fixed at 1200 in this file, with the host and container sides mapped identically, so putting RSSHub behind anything on the same machine means remapping the left side. And a three-retry, thirty-second-interval probe gives a process up to roughly a minute and a half of trouble before the container is called unhealthy, which is shorter than a route that depends on a slow third-party site. The browserless service has its own probe against localhost:3000/pressure, and RSSHub's depends_on lists redis and browserless, so a failed browser container keeps the application from starting even for routes that never need a browser.

## Five build targets from one set of route files

The script list in package.json is the clearest statement of what this project is: a route collection compiled into five different products. The default build runs the route build then tsdown, the library build uses tsdown-lib.config.ts, the docs build hands off to a script, and the worker routes are compiled with WORKER_BUILD=true. Cloudflare gets its own path, where container-deploy builds and then calls wrangler with a wrangler config and an immediate rollout:

```json
"container-deploy": "npm run container-build && wrangler deploy --config wrangler-container.toml --containers-rollout=immediate"
```

At the repository root that spread is visible as files rather than prose: fly.toml, vercel.json, app.json, wrangler.toml, wrangler.production.toml, wrangler.container.toml, and four tsdown configs split across lib, container, vercel and worker. Route files are not loaded at runtime from a folder you can edit. They are compiled by a build step, so a route change is a build and a deploy, not a file drop. Contributors get a dev script that watches lib/index.ts, and the same script raises the HTTP header ceiling to 32768 bytes for local work.

## The npm package ships dist-lib and nothing else

The publish configuration is short enough to read in full, and it narrows what npm install rsshub gives you:

```json
    "files": [
        "dist-lib"
    ],
    "type": "module",
    "exports": {
        ".": {
            "types": "./dist-lib/pkg.d.mts",
            "import": "./dist-lib/pkg.mjs"
        }
    },
```

The files array lists a single directory and the only export entry points at a module inside it. That is the library build, produced by the script that uses tsdown-lib.config.ts, not the HTTP service. If you were expecting npm to give you a runnable RSSHub, it does not: the README points at the Docker image diygod/rsshub, its ghcr.io mirror, and the hosted instance for that, and at docs.rsshub.app for how to run it. The practical consequence for a Node shop is that RSSHub is something you deploy, not something you require, unless you are embedding route logic in your own build.

## Chromium is skipped at image build time, on purpose

The Dockerfile explains its own trade-off in comments. The dependency stage installs with the browser download disabled, which keeps the image small and the build cache stable:

```dockerfile
RUN \
    set -ex && \
    export PLAYWRIGHT_SKIP_BROWSER_DOWNLOAD=true && \
    pnpm install --frozen-lockfile && \
    pnpm rb
```

A separate stage then greps package.json for the patchright, @vercel/nft and fs-extra versions and writes them to files, so that editing an unrelated dependency does not invalidate the next build stage. The build also takes a USE_CHINA_NPM_REGISTRY argument that repoints npm, yarn and pnpm at a mirror. Add those up and the picture is coherent: the image ships no browser on purpose, which is exactly why docker-compose either points PLAYWRIGHT_WS_ENDPOINT at a separate browserless container or asks you to pull the chromium-bundled tag instead. Routes that need to render JavaScript are the ones that make this choice expensive.

## Folo and Radar read the feeds, they do not replace the routes

The related projects list is a map of the ecosystem and it is worth reading as one. Folo is an AI RSS reader that the README says pairs well with RSSHub, RSSHub Radar is a browser extension for discovering and subscribing to the RSS or RSSHub feed of the page you are on, RSSBud and RSSAid are the iOS and Android equivalents, DocSearch wires the documentation into Raycast, and Awesome RSSHub Routes is a curated list maintained outside the repository. All of them sit on the consumption side. That is the structural difference from a self-hosted aggregator such as FreshRSS: RSSHub manufactures feeds from sources that do not publish them, while an aggregator reads feeds that already exist. The two compose rather than compete. The cost of that design is that every route is a scraper for somebody else's site, and when that site changes, the feed is what breaks, with a GitHub Actions test workflow on pushes to master as the only signal the README offers.

## Conclusion

Run RSSHub yourself when a source has no feed and you want to keep the aggregation under your control, and expect to own a Redis cache, a headless browser and the breakage of every route you depend on. Do not pick it as a reader, because the project ships no reader, and do not pin by package version, since package.json says 1.0.0 and the repository has no GitHub releases. Verify three things before the first route goes into a production reader: that the docker-compose environment you copied still matches the image tag you pulled, that PLAYWRIGHT_WS_ENDPOINT is set or you switched to diygod/rsshub:chromium-bundled, and that the healthcheck at http://localhost:1200/healthz returns before you point a subscription at it.

## FAQ

### What does RSSHub do?

It aggregates content from sources that do not publish feeds and serves it as RSS. The README describes a network of over 5,000 global instances delivering millions of aggregated items, and its motto is that everything is RSSible.

### How to install RSSHub?

The docker-compose file runs the image diygod/rsshub, publishes port 1200, sets CACHE_TYPE to redis with a redis service, and can point PLAYWRIGHT_WS_ENDPOINT at a browserless service. The README sends you to docs.rsshub.app/deploy/ for the deployment guide and offers a pre-configured single click option on Hostinger.

### Is RSSHub safe to run?

Running it means running a fetcher for third-party sites, which is why the compose file ships a separate headless browser and a Redis cache rather than nothing. The repository includes a SECURITY.md, and routes are compiled at build time from files under lib/ rather than loaded from a directory you can edit at runtime.

### Is RSSHub free to use?

The project is released under the AGPL-3.0 license by DIYgod. The container image, its ghcr.io mirror, the npm package and the hosted instance at rsshub.app are all linked from the repository README.

### RSSHub vs FreshRSS: which one do I need?

They do different jobs. RSSHub generates feeds from sources that have none, with routes compiled at build time, while FreshRSS is a self-hosted aggregator that reads feeds you already have. The projects listed around RSSHub, such as Folo, RSSHub Radar, RSSBud and RSSAid, are all readers or discovery tools on the consumption side.

## Sources

- [Official documentation](https://docs.rsshub.app)
- [Official README](https://github.com/DIYgod/RSSHub#readme)
- [Project repository](https://github.com/DIYgod/RSSHub)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/diygod-rsshub