RSS-to-Telegram-Bot: a self-hosted feed reader that posts into Telegram

What RSStT solves for people who read inside Telegram

Most feed readers assume you will open a separate app. RSStT assumes the opposite: your reading surface is a Telegram chat, and feeds should arrive there as messages you can scroll, forward and search. The README describes it as "a Telegram RSS bot that cares about your reading experience", and the feature list is written around that premise rather than around feed management.

The target user is someone who already runs a small server or a PaaS account and wants a private instance rather than the public @RSStT_Bot. The public bot exists, but the README states plainly that it "comes with absolutely no warranty" and that maintenance is best-effort. Self-hosting is the path the project actually recommends, and the repository supports it with a Dockerfile, a docker-compose.yml.sample, a Procfile for PaaS, and an app.json for Railway. Multi-user support is listed as a highlight, so one instance can serve several Telegram accounts.

The problem it solves is narrower than "RSS". It is the conversion problem: taking a feed item with HTML, images, video, audio and enclosures and turning it into something Telegram will render without mangling it. That is where most feed-to-chat scripts fail, and it is where RSStT spends its complexity.

How the bot turns a feed item into a Telegram message

The pipeline is visible from the repository layout and the dependency list. Feed retrieval and parsing go through feedparser, with lxml and beautifulsoup4 for markup handling and listparser for OPML import and export. Media handling uses pillow for images and matplotlib, which the README's media section implies is used for generated visuals. minify-html and minify-html-onepass suggest the bot rewrites post HTML before sending rather than passing it through untouched.

The Telegram side is Telethon, with cryptg for faster MTProto encryption and aiographfix for the Telegraph publishing path. The README lists Telegraph posts as an optional delivery format for messages that are too long or too media-heavy for a normal message. That is a real architectural decision: instead of truncating, the bot can publish the content elsewhere and send a link.

Persistence sits behind tortoise-orm with two backends, asyncpg for PostgreSQL and aiosqlite for SQLite. Migrations are handled by aerich, and setup.py explicitly bundles the src/db/migrations_* directories into the package because they are not importable Python packages. Networking is aiohttp with aiohttp-socks and python-socks, which is what makes the per-target proxy configuration in the README possible: Telegram and feed fetching can each use a different proxy. APScheduler drives the periodic feed polling, and the README claims HTTP caching as a feature, which matters when a single instance polls many feeds.

The formatting layer is where the project has invested most: emoji shortcode replacement, emoji image replacement with fallback text, detection of auto-filled feed titles so they can be omitted, automatic author display, message splitting, and configurable hashtags. These are documented in docs/formatting-settings.md rather than in the README.

Deploying RSStT with Docker Compose and adding a first feed

The README names Docker Compose as the most recommended deployment method and says it suits virtually all VPS. The repository ships docker-compose.yml.sample and .env.sample, so the starting point is copying both and filling in the environment file. The README does not reproduce the full variable list on the front page; it points to docs/deployment-guide.md, and that is where you should read before running anything.

A minimal Docker Compose setup follows the sample file's shape. The image on Docker Hub is rongronggg9/rss-to-telegram, and the service reads its configuration from the env file you create next to it.

cp docker-compose.yml.sample docker-compose.yml
cp .env.sample .env
docker compose up -d

After the container starts, the bot needs a Telegram bot token and at least one allowed user. Those keys live in the .env file, and the deployment guide is the authority on their exact names and accepted values. If you prefer not to run Docker at all, the README states you can install from PyPI, where the rsstt package tracks the master branch, or from TestPyPI, which tracks dev and is described as always up to date.

pip install rsstt

Once the instance is running, the workflow is conversational. You send the bot a feed URL in a private chat and it subscribes that chat to the feed; the README's OPML section means you can also import an existing subscription list and keep your custom feed titles. Formatting is adjusted per feed through the bot's own settings rather than by editing files, and docs/formatting-settings.md documents the available knobs. Railway.app is officially supported as an alternative if you do not want to manage a VPS, and the README links a deploy button for it.

Where RSStT gets awkward: maintenance, database choice and delivery limits

The most concrete limitation is stated by the project itself. The repository description carries a call for new maintainers pointing at issue 747. A project that is explicitly asking for maintainers is telling you something about bus factor, and it should shape how you plan upgrades. The last push was on 2026-08-31, and the most recent release listed is v2.10.0 from 2025-03-22, so release cadence and commit cadence are not the same thing here.

The second constraint is the database. Both SQLite and PostgreSQL are supported, and requirements.txt pins aiosqlite below 0.22 with a comment that aiosqlite 0.22 and later is incompatible with tortoise-orm 0.25.1's SQLite backend. That is a pinned workaround, not a preference, and it means a future upgrade of either library has to be checked together. If you run PostgreSQL you avoid that specific pin, at the cost of running another service.

The third is delivery. Telegram imposes message size and media limits, and RSStT's answer is to split long messages and to offer Telegraph posts as an alternative format. Telegraph is a Telegram-owned publishing surface, so choosing that path means your content lives on a third-party domain rather than in the chat. The README lists it as customizable, which is the right framing: it is a trade-off, not a free win.

Finally, this is the wrong tool if you want a reading interface with unread counts, folders, keyboard navigation and offline sync. RSStT pushes content into a chat. It is not a reader application, and the README does not claim otherwise.

RSStT compared with a conventional self-hosted feed reader

The obvious alternative category is a self-hosted web feed reader such as FreshRSS or Miniflux, which store articles in their own database and render them in a browser or a mobile client. The difference in approach is where the article lives. A conventional reader keeps a copy and gives you a UI to triage it; RSStT keeps no reading UI at all and instead converts each item into a Telegram message, then lets Telegram be the interface.

That changes what you get. A conventional reader gives you unread state, starred items and full-text search across everything you have ever fetched. RSStT gives you Telegram's own search, forwarding, and the ability to read on any device where you are already signed in, with no separate app to install. For a user who checks Telegram constantly and never opens a reader app, that is a genuine improvement in the chance the feed actually gets read.

The cost is control over presentation. A web reader can render arbitrary HTML faithfully because it controls the viewport. RSStT has to fit content into Telegram messages, which is why the project spends so much code on splitting, media re-encoding, emoji substitution and Telegraph fallback. If your feeds are mostly long-form articles with complex layout, a web reader will represent them more faithfully. If your feeds are link-heavy news, release notes or image posts, the Telegram format loses very little.

Licence and the cost of staying current

RSStT is licensed under AGPL-3.0, and setup.py carries the standard AGPL header with the warranty disclaimer. The practical consequence of the AGPL for a self-hoster is the network clause: if you modify the bot and let other people interact with it over a network, the licence expects you to offer those users the corresponding source. Running an unmodified instance for yourself and a few friends is the ordinary case, but if you plan to operate it as a service for others, that obligation is worth understanding before you start. This is a description of the licence text, not legal advice.

Upgrade cost is dominated by two things. The first is the pinned dependency set in requirements.txt, which is unusually long and includes several version-exact pins with explanatory comments, such as the aiosqlite and asyncclick entries. Bumping one library can require bumping tortoise-orm, which can require a database migration through aerich. The second is the migration directories bundled by setup.py; they ship with the package, so migrations run as part of the normal upgrade path rather than as a manual step you might forget.

Because the dev branch is the default branch and TestPyPI tracks it, the bleeding-edge install and the stable install are different artefacts. The README frames PyPI as tracking master and TestPyPI as tracking dev. If you want predictable upgrades, install from PyPI and read docs/CHANGELOG.md before moving versions.

Editorial conclusion

Adopt RSStT if you want feed reading inside Telegram and are willing to run a container, a bot token and a database. Skip it if you need a zero-maintenance hosted reader or cannot accept AGPL-3.0 obligations. Before deploying, read docs/deployment-guide.md for the environment variables, confirm whether you want SQLite or PostgreSQL, and check the maintainer call in issue 747 to judge how much upstream help you can expect.

Frequently asked questions

Official sources

1. License: AGPL-3.0
2. Project website
3. README
4. Releases
5. Rongronggg9/RSS-to-Telegram-Bot on GitHub