tt-rss after the fork: the community continues the feed reader that retired

A fork cut 29 days before the original went away

The context matters more than the feature list here. The README states that the original tt-rss project, hosted at tt-rss.org and its subdomains, was retired on 2025-11-01, and it credits fox for creating and maintaining the project. This repository is a fork of tt-rss as of 2025-10-03, created by one of the original's long time contributors, `wn_` on tt-rss.org and `supahgreg` on GitHub. The stated goal is to continue tt-rss development, and the policy is explicit: no major breaking changes are planned. So this is not a redesign with a new configuration format and a new database schema. It is the same web based reader and aggregator, carried forward by a maintainer who already knew the codebase.

Images for amd64 and arm64 published to two registries

Packaging was rebuilt rather than inherited. The README says Docker images for `linux/amd64` and `linux/arm64` are built and published via GitHub Actions, and calls them drop-in replacements for the old images. They land in two places. On Docker Hub the names are `supahgreg/tt-rss` and `supahgreg/tt-rss-web-nginx`. On the GitHub Container Registry the names are `ghcr.io/tt-rss/tt-rss` and `ghcr.io/tt-rss/tt-rss-web-nginx`. Tags on the `main` branch, plus `latest` and the most recent `sha-*` tag for the Docker images, are intended to be stable and safe for use, and the README states that using the latest code or image is strongly encouraged, which it says may be a prerequisite to getting support in certain situations.

The compose file in the repo is for development, not production

The repository ships a `docker-compose.yml`, and it opens with a warning worth quoting in full: it is a simplified compose for local development, and please do not use it in production because it has no database persistence and maps to tt-rss source directly. Even so, it is the clearest picture of the deployment shape. The `db` service runs `postgres:15-alpine` and takes its credentials from a `.env` file through `POSTGRES_USER`, `POSTGRES_PASSWORD` and `POSTGRES_DB`. The `app` service builds from `.docker/app/Dockerfile` and runs `ghcr.io/tt-rss/tt-rss:latest`. A separate `updater` service runs the same image with a different command:

  updater:
    image: ghcr.io/tt-rss/tt-rss:latest
    restart: unless-stopped
    command: /opt/tt-rss/updater.sh

The web tier is a separate container that mounts the source read only and publishes a configurable port:

    ports:
      - ${HTTP_PORT}:80
    volumes:
      - .:/var/www/html/tt-rss:ro

The `HTTP_PORT` value comes from your own `.env` file, and a `.env-dist` file in the repository root is the starting point for it.

The codebase layout tells you what the application does

This is a large PHP application with a classic front controller layout, and the top level entries show the moving parts. `index.php` and `backend.php` sit at the root, with `api/` for the API layer, `classes/` for the model and service code, and `include/` for shared includes. Feeds are stored in the database, with `sql/` and `schema/` directories holding the database side, while `update.php` and `update_daemon2.php` handle the background fetching cycle that populates them. Everything you can extend lives in a local directory you are meant to write into: `plugins.local/`, `themes.local/` and `templates.local/`, next to the shipped `plugins/`, `themes/` and `templates/`. That pairing is the extension model, and it is why an upgrade does not have to touch your own code.

Plugins moved to GitHub and were renamed on the way

Extension authors had to make one concrete change. Plugins that lived under the GitLab instance at gitlab.tt-rss.org have been mirrored to GitHub, and the README states that plugin repository names have changed to get a consistent `tt-rss-plugin-*` prefix. That is a rename of addresses, not just of hosting, so any plugin install that referenced the old GitLab paths will not resolve as written. The local override directories, `plugins.local/` and `themes.local/`, are where your own copies belong, which keeps local modifications separate from the tracked ones. The README does not describe a plugin API version number or a compatibility matrix, so how far individual plugin repositories have tracked the fork is something you have to check per plugin rather than assume from the core release.

Documentation moved too, and the old web repository is archived

The documentation surface was reorganised in the same sweep. Content that lived at tt-rss.org has been recreated in the `tt-rss.github.io` repository, which the README calls the new source for the tt-rss.org content. The original repository that held the website content was mirrored to `tt-rss-web-static`, where some content tweaks were made after the mirroring and before the new repository was set up, and that repository is now archived. The README still points readers to the installation guide on tt-rss.org for setup instructions, so the guide remains the entry point even though its source moved. Contributors are pointed at `CONTRIBUTING.md` for how to submit code, translations and issue reports.

GPL-3.0, the Debian PHP rule, and a repository without releases

Licensing is straightforward and unchanged from upstream. The project is free software under the GNU General Public License, version 3 of the License or, at your option, any later version, and the copyright notice goes back to Andrew Dolgov in 2005 unless stated otherwise. For a self hosted service that means your modifications stay under the same terms when you redistribute them. The PHP floor is defined indirectly: the minimum PHP version supported will match what is in Debian's current `stable` release, so the runtime follows the distribution rather than a fixed number in the README. On the release side, there are no GitHub releases for this repository. The last push was on 2026-10-18, and the project tracks upstream code by commit, so there is no tagged version to pin to.

What actually differs from the project it forked

The honest comparison is with the original tt-rss, and the difference is about who maintains it and where the artefacts live rather than about features. The original site and its subdomains were retired on 2025-11-01, so there is no longer an upstream to wait for. This fork keeps the same application, the same installation guide link and the same policy of no planned breaking changes, while moving four things onto GitHub: container images published through GitHub Actions, the documentation source, the static website repository, and the plugin repositories with their new prefix. For anyone already running tt-rss, that is a migration of addresses rather than a migration of configuration, and the `sha-*` image tags are what let you pin a specific commit when you need the old behaviour for a moment.

Editorial conclusion

Adopt the tt-rss fork if you already run tt-rss and need the project to keep moving, since the upstream site was retired on 2025-11-01 and this fork carries the same application forward with published container images for linux/amd64 and linux/arm64. Do not adopt it expecting a different product, because the goal stated by the maintainer is to continue tt-rss development with no major breaking changes planned. Verify first that the plugins you rely on exist under the new `tt-rss-plugin-*` repository names, and read the installation guide referenced by the README before changing any existing deployment.

Frequently asked questions

Official sources

1. Issues
2. License: GPL-3.0
3. README
4. tt-rss/tt-rss on GitHub