RSSBox: self-hosted RSS translation and AI filtering, reviewed

What RSSBox actually does to a feed

A normal feed reader fetches a URL and renders whatever the publisher put there. RSSBox sits one step earlier. You give it a source feed, and it produces a second feed that you subscribe to instead. Between those two points it can translate the title, translate the content, or summarize, and it can display the original and the translated text side by side. The README lists these as separate features, and the distinction matters: translating only titles is cheap and keeps the layout of the original item, while translating content or generating a summary rewrites the body and changes how the item reads in your client.

The project describes itself as the former RSS Translator, so the translation path is the oldest part of it. The newer additions are the ones that make the tool interesting beyond language: keyword filtering, what the README calls AI intelligent filtering, full-text retrieval, and merging several sources into one feed through tags. That last one is a structural change rather than a text change. If you tag five feeds with the same label, RSSBox can emit a single combined feed, and filters can be applied to the merged result rather than to each source separately.

The audience is narrow and specific. This is for someone who already has a reader, already has a list of sources in a language they do not read fluently, and is willing to run a service to fix that. It is not a reader itself, and the README never presents it as one.

The pipeline: Django, Redis, cron, and a rewritten feed

The repository layout tells you most of the architecture. There is a config/ directory holding Django settings, a core/ app, a utils/ package, templates/, and a manage.py at the top level. The dependency list in pyproject.toml names Django 5.2 or newer, Redis, feedparser and feedgen, feed2json, newspaper4k and lxml for article extraction, html2text and mistune for converting markup, tiktoken for counting tokens, and both the deepl and openai clients. Python 3.12 or newer is required.

That combination points to a straightforward flow. A scheduled job pulls each source feed with feedparser, optionally fetches the full article with newspaper4k, sends the text to a translation engine or an OpenAI-compatible model, and then writes the result back out through feedgen or feed2json. Redis is present as the queue or cache layer between the fetch and the write. The Dockerfile installs cron, gettext and gosu, and copies a file named config/rt_cron, which is where the recurring work is scheduled. So the update rhythm of a translated feed is not driven by your reader polling it; it is driven by the container's cron entries, and the README lists control over update frequency and visibility into translation status as features.

Two details in the dependency list are worth noting because they shape what you can audit. django-encrypted-model-fields is included, which suggests API keys and other credentials are stored encrypted in the database rather than in plain text. And tiktoken is included alongside the per-source token and character counters the README mentions, so the cost reporting is computed from token counts rather than from a rough estimate.

Installing RSSBox and subscribing to your first translated feed

The README does not contain a deployment section; it links to rssbox.app for documentation and shows a Docker image badge for versun/rssbox. The Dockerfile is the concrete artifact in the repository, so the commands below follow what it assumes rather than inventing a configuration. Note that the Dockerfile's own comments show the image being built and pushed under the versun/rssbox tag; there is no documented docker run invocation in the repository, so the container command below is the minimal form implied by the Dockerfile's PORT setting.

The image is built on python:3.13-slim-bookworm and sets PORT to 8000, so a container run needs that port published. The Dockerfile also expects config/rt_cron to be present for the cron schedule, and it installs gosu, which is the usual pattern for dropping privileges at startup.

ENV PYTHONDONTWRITEBYTECODE=1 \
    PYTHONUNBUFFERED=1 \
    PATH="/opt/venv/bin:$PATH" \
    PORT=8000 \
    DockerHOME=/app \
    PYTHONPATH="/app"

For development against a checkout rather than the image, the README gives a single entry point. The pyproject.toml defines it as a project script, and the README says it installs dependencies and completes initialization on its own.

uv run dev

The same file defines two other scripts, server and init, which map to scripts.prod_server:main and scripts.init:init_server. Those are the production and initialization entry points; the README documents only the development one.

Once the service is up, the first real use is a source. You add the feed URL, choose a translation engine for that source (the README states each source can be assigned its own engine), and decide whether to translate the title, the content, or to summarize. The output is a new feed URL that you paste into your reader. From that point on, what your reader sees is whatever RSSBox last produced, not what the publisher last published. The README also mentions a demo at rssbox.app/demo/ if you want to see the interface before running anything.

Where RSSBox is the wrong tool

The strongest argument against RSSBox in some setups is that it puts a machine between you and the source. Every item you read has passed through a translation engine or a language model, and the translated or summarized version is what gets stored and served. If you need the publisher's exact wording, or if you are reading feeds where a mistranslated clause changes the meaning, the translated feed is not a substitute for the original. The README does not describe a per-item fallback to the original text when a translation fails, and it does not document rollback of a bad batch.

Cost is the second boundary. Translation engines and OpenAI-compatible models are billed per character or per token, and RSSBox tracks both per source, which implies the bill is real and worth watching. A feed that updates every few minutes, or a full-text retrieval setting applied to a high-volume source, multiplies that. The token counters exist precisely because this is easy to get wrong.

Operationally, this is a Django application with Redis and cron inside the container. That is more moving parts than a static feed proxy, and the failure modes are the ordinary ones: a cron entry that does not fire, a Redis instance that is not reachable, an API key that expires and silently stops translations. The README lists translation status as a viewable feature, which is the intended way to notice, but nothing in the repository description suggests alerting. If you want a reader and nothing else, this is a service you would be maintaining for no benefit.

RSSBox against a plain reader with built-in translation

The obvious alternative is to skip the middleware and use a feed reader that translates on display, or a browser translation feature over the reader's web interface. The difference in approach is where the work happens and what persists. A reader that translates at render time keeps the publisher's feed as the source of truth; nothing is stored, and if the translation is bad you can turn it off for one article. RSSBox inverts that: the translation happens once, upstream, and the result is a feed in its own right, which is why it can be subscribed to from any client, including one with no translation support at all, and why it can be merged with other feeds through tags.

That trade is the whole product. You gain client independence and the ability to combine and filter sources before they reach you. You lose the ability to see the original without going back to the source feed, and you take on the cost and the operational surface. A reader with built-in translation is the better answer for a handful of foreign-language feeds you read casually. RSSBox is the better answer when the translated feed needs to behave like any other feed in your setup, or when the filtering and merging are the point rather than the translation.

Licence, releases and the cost of staying current

RSSBox is GPL-3.0. For self-hosting that is unremarkable: you can run it, modify it and redistribute it under the same terms, and if you offer a modified version to others as a network service, the licence's copyleft terms are the thing to read carefully. This is not legal advice, and the LICENSE file in the repository is the authoritative text.

The release cadence visible in the repository is fast. Version 2026.8.4 was published on 2026-08-04, 2026.9.5 on 2026-09-05, and 2026.9.6 on 2026-09-06. Version numbers track dates, so the project's own versioning tells you how far behind you are. The last push to the default branch was on 2026-09-06.

A cadence that tight cuts both ways. Fixes arrive quickly, and so do changes you did not ask for. Pinning to a specific tag rather than latest is the practical response, and the Dockerfile's own comments show multi-arch build and push commands for versun/rssbox tags, which is the mechanism the maintainer uses to publish them. The upgrade cost itself is not documented in the README: there is no migration or rollback section, and the repository has a config/ directory with settings and a dev-diaries/ directory that may hold the reasoning, but the README does not point to an upgrade procedure. Treat a version bump as something to test against a copy of your database first.

Editorial conclusion

RSSBox fits readers who already run a feed reader and want translation, summaries or keyword filtering applied upstream, before the items reach the client, and who are willing to keep a Django plus Redis service, API keys and a cron schedule alive. It is the wrong choice if you only need a plain reader, if you do not want translated or machine-generated text stored in your own database, or if you cannot supply a DeepL or OpenAI-compatible endpoint. Verify first that the Docker image tag you intend to pin exists, that config/rt_cron matches the update intervals you want, and that the translation engine you plan to use is reachable from the container.

Frequently asked questions

Official sources

1. License: GPL-3.0
2. Project website
3. README
4. Releases
5. versun/RSSBox on GitHub