# RSS-Bridge: generating feeds for sites that never shipped one > RSS-Bridge is a PHP web application that turns pages without a feed into RSS, Atom or JSON. It installs as a zip on shared hosting, as a Composer project, or as a Docker container on port 3000, and its 447 bridges decide how far it gets you. **RSS-Bridge/rss-bridge** — The RSS feed for websites missing it - Repository: https://github.com/RSS-Bridge/rss-bridge - Website: https://rss-bridge.org/bridge01/ - Stars: 9,258 · Forks: 1,248 - Language: PHP - License: Unlicense - Published: 2026-09-21 · Updated: 2026-09-21 · Language: en - Canonical page: https://hysenlabs.com/projects/rss-bridge-rss-bridge ## What RSS-Bridge solves, and for whom The project describes itself as a PHP web application that generates web feeds for websites that don't have one. That sentence is the whole product. You point it at a bridge, give the bridge the parameters it wants (a username, a channel, a search term, a URL), and it returns a feed you can paste into any reader. The output formats are RSS, Atom and JSON, which is why the repository carries atom-feed and json-feed topics alongside rss-feed. The intended user is someone who already has a feed reader and a list of sites that refuse to publish one. A self-hoster with a small VPS. A person on shared hosting who can unzip a folder into a web directory. The README also points at a hosted instance at rss-bridge.org/bridge01 and a page listing other public instances, so you can evaluate the concept before installing anything. That matters, because the interesting question with RSS-Bridge is never whether it runs. It is whether the specific bridge you need still works. ## How a bridge turns a page into a feed The repository layout makes the architecture legible. There is index.php at the top, and beside it directories named bridges/, formats/, lib/, middlewares/, templates/, actions/, cache/ and caches/. A request arrives at index.php, the application selects a bridge from bridges/, the bridge fetches the remote page and extracts items, and a format class under formats/ serialises the result as RSS, Atom or JSON. The middlewares/ directory sits in that path, and cache/ and caches/ hold fetched content so repeated requests do not hammer the source site. That separation is the reason the project scales to a large bridge count. A bridge author writes extraction logic only; the feed serialisation and the HTTP surface are shared. The README lists 447 bridges in total and shows a subset of 15, and the subset is instructive about the two families. Some bridges are site-specific: YoutubeBridge fetches videos by username, channel, playlist or search, RedditBridge fetches posts from a user or subreddit with filtering options, MastodonBridge reads statuses from an ActivityPub instance, TelegramBridge reads posts from a public channel. Others are generic and do no site-specific work at all. CssSelectorBridge scrapes a feed using CSS selectors, XPathBridge does the same with XPath expressions, and FeedMergeBridge, FeedReducerBridge and FilterBridge operate on feeds you already have rather than on pages. That second family is the more durable half. A selector-based bridge depends on your selector, not on a maintainer's guess about a site's markup, so it does not break when the project's own bridge for that site rots. The site-specific bridges are the opposite: convenient when they work, and dependent on someone else's maintenance when they do not. ## Installing RSS-Bridge and generating a first feed The README gives the shortest path first: RSS-Bridge can basically be unzipped into a web folder and should be working instantly. It links a zip of the master branch, about 2MB. The documented minimum is PHP 7.4. For a real server the README walks through Debian 12 with nginx and php-fpm, including the packages to install: ```bash apt install git nginx php8.2-fpm php-mbstring php-simplexml php-curl php-intl ``` The nginx configuration it provides is deliberately narrow. Static assets are served from a location /static/ block, and PHP is reached only when the request path is exactly /, which keeps the application from exposing anything else through the web server. The Docker route is the least work, and the repository ships a docker-compose.yml that maps container port 80 to host port 3000: ```yaml version: '2' services: rss-bridge: image: rssbridge/rss-bridge:latest volumes: - ./config:/config ports: - 3000:80 restart: unless-stopped ``` After docker compose up, the web interface is on http://localhost:3000. Pick a bridge from the list, fill in its parameters, and the page gives you the feed URL to paste into your reader. The CssSelectorBridge is the one to try first if your target site has no dedicated bridge: you supply a URL and a CSS selector, and the bridge returns the matched items as a feed. Composer is the third documented option, and it installs a release rather than the master branch: ```bash cd /var/www composer create-project -v --no-dev --no-scripts rss-bridge/rss-bridge ``` The README notes that copying config.default.ini.php to config.ini.php is optional, which tells you the application runs with defaults and you only create the file when you want to change something. The Debian instructions also set a PHP execution time of 15 seconds and a memory limit of 64M, and the fpm pool respawns a worker after 500 requests as a workaround for memory leaks. Those numbers are a fair signal of the expected workload: short requests, modest memory, and a process that is not trusted to stay clean indefinitely. ## The bridge is the failure mode RSS-Bridge does not scrape sites generically. Each bridge encodes an assumption about one site's HTML or API, and when that site changes, the bridge returns nothing or returns garbage until someone fixes it. The README does not document any health check, deprecation warning or automatic disable for a broken bridge, and it does not document rollback. Your reader will simply stop showing new items. The practical consequence is that a self-hosted instance is a maintenance commitment proportional to how many bridges you depend on. One CssSelectorBridge targeting a stable page is close to zero upkeep. Ten site-specific bridges for social platforms is a different proposition, and those platforms are exactly the ones with an incentive to change markup or block automated requests. The Dockerfile gives a partial answer to that: it installs libcurl-impersonate, a patched curl library, which exists because some sites reject requests that look like a script. That is a workaround for bot detection, not a guarantee against it, and it is the kind of dependency that has to be kept current. There is also a scoping limit worth stating plainly. Nothing in the README describes logging into a service, handling authenticated sessions or paying for API access. If your target requires an account, RSS-Bridge is the wrong tool. ## RSS-Bridge against RSSHub and against writing your own scraper The obvious comparison is RSSHub, which people search for directly. Both generate feeds for sites that lack them, and both are self-hostable. The difference in approach is the unit of extension. RSS-Bridge is a PHP application whose bridges live in the repository and are selected through a web interface, with a per-bridge parameter form and a hosted instance you can try without installing. RSSHub is a Node.js project whose routes are likewise contributed by its community. If your infrastructure is PHP or you want a browser-based picker rather than a URL convention, RSS-Bridge fits more naturally; if it is Node, the reverse. The README does not compare the two, so treat the bridge coverage for your specific sites as the deciding factor rather than the language. The other alternative is a small scraper you write yourself. That gives you exactly one extraction rule to maintain, no dependency on a bridge author's schedule, and no web application to host. What you give up is the format layer, the caching, the middlewares and the parameter UI, all of which RSS-Bridge already provides. For a single site, a script is often less work. For a dozen sites across different platforms, the shared machinery starts to pay for itself. ## Maintenance, releases and the Unlicense The last push to the default branch was on 2026-08-28, and the most recent release is dated 2025-08-05, with earlier releases on 2025-06-03 and 2025-01-26. The repository is not archived. Releases are versioned by date rather than by semantic version, so RSS-Bridge 2025-08-05 is the release name you would see, and there is no documented long-term support branch. If you install from Composer you get a release; if you clone master or use the latest Docker image you get whatever is on the branch at pull time, and the Dockerfile builds from debian:12-slim with PHP 8.2 packages, so a PHP upgrade in the base image is a change you inherit. The licence is the Unlicense, which the repository includes as a file named UNLICENSE. That is a public-domain dedication rather than a permissive licence with attribution conditions, and it means there are no attribution or copyleft obligations attached to the code. It says nothing about the sites you scrape: the licence covers RSS-Bridge, not the content a bridge retrieves, and the README does not address terms of service for the sources. That question is yours to answer, and it is not a legal question this article can settle. ## Conclusion Adopt RSS-Bridge if you already run PHP or a container host and you accept that individual bridges break when the sites they scrape change. Do not adopt it as a general-purpose scraper for logged-in, paywalled or heavily bot-protected services; the project ships no account integration and the bridge list is the whole capability surface. Before committing, open the bridge you actually need on the hosted instance, confirm it still returns items, then check that your PHP version meets the documented minimum of 7.4 and that config.ini.php exists if you plan to change any setting. ## FAQ ### How do you use RSS-Bridge? You run the PHP application, open its web interface, and pick a bridge for the site you want. You fill in that bridge's parameters, such as a username or a channel, and the page gives you a feed URL in RSS, Atom or JSON that you paste into a feed reader. ### What is RSS-Bridge? It is a PHP web application that generates web feeds for websites that don't have one, according to the README. The repository lists 447 bridges, some targeting specific sites and others, such as CssSelectorBridge and XPathBridge, scraping any page you supply selectors for. ### How does RSS-Bridge compare with RSSHub? Both generate feeds for sites that lack them and both are self-hostable, but RSS-Bridge is a PHP application with bridges selected through a web interface, while RSSHub is a Node.js project. The README does not compare them, so the bridge coverage for your specific sites is the practical difference. ## Sources - [License: Unlicense](https://github.com/RSS-Bridge/rss-bridge/blob/master/LICENSE) - [Project website](https://rss-bridge.org/bridge01/) - [README](https://github.com/RSS-Bridge/rss-bridge/blob/master/README.md) - [Releases](https://github.com/RSS-Bridge/rss-bridge/releases) - [RSS-Bridge/rss-bridge on GitHub](https://github.com/RSS-Bridge/rss-bridge) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/rss-bridge-rss-bridge