MrRSS: an AI RSS reader that also runs headless with Docker

What MrRSS is for, and who should care

MrRSS is a feed reader that adds machine translation and summarization on top of ordinary RSS and Atom subscriptions. The problem it targets is specific: a reader who subscribes to sources in more than one language, or to sources that publish long articles, spends most of the reading session skimming rather than reading. MrRSS takes the feed items, translates titles and content, and produces short summaries so a queue can be triaged before anything is opened.

The audience is narrower than "anyone who reads RSS". The README lists Obsidian, Notion, FreshRSS and RSSHub as plugin integrations, which tells you the intended user already runs a personal knowledge base or an existing feed service and wants MrRSS as the reading front end. A second audience is the self-hoster: the same codebase builds with a server tag and runs behind Docker, so the reader can live on a box rather than a laptop. Someone who just wants a minimal offline feed reader will find more machinery here than they need.

How the pieces fit: Wails desktop, Go core, SQLite store

The architecture is a Go application with a Vue 3.5 front end rendered through Wails v3. The Go side carries the feed work: gofeed for parsing, goquery and cascadia for HTML, xmlquery and htmlquery for XPath-style extraction, and go-readability for pulling article bodies out of pages that do not publish full text. That dependency list is the clearest statement of how MrRSS handles the messy half of feed reading, where a subscription is not a clean XML document but a page that has to be scraped.

Storage is SQLite through modernc.org/sqlite, a pure-Go driver with no CGO requirement for the database itself. Language handling uses whatlanggo for detection, gse for Chinese segmentation, and opencc for Chinese script conversion, which explains why translation quality is a stated goal rather than an afterthought. chromedp is also in the dependency list, so some feeds are expected to need a real browser engine to render before extraction. That is a heavy dependency to carry for the subset of feeds that need it, and it is the kind of trade-off worth knowing about before you build from source.

The desktop build and the server build diverge at the entry point: main.go and main-core.go sit alongside desktop_window.go and desktop_rendering.go, and the server binary is produced with a build tag rather than a separate repository. One codebase, two front ends, one data model.

Installing MrRSS from a release installer

The README recommends the pre-built installer over building from source. Release assets follow a predictable naming scheme per platform, so you pick the file matching your OS and architecture rather than running a package manager command. Windows gets `MrRSS-{version}-windows-amd64-installer.exe` or the arm64 equivalent, macOS gets a universal `MrRSS-{version}-darwin-universal.dmg`, and Linux gets `MrRSS-{version}-linux-amd64.AppImage` or the arm64 AppImage.

Portable builds exist for people who do not want an installer touching the system. On Windows and macOS these are zip archives, on Linux a tarball, and the README lists `MrRSS-{version}-linux-{arch}-portable.tar.gz` among the portable assets.

After extraction, the portable build switches storage behaviour. The README states that when a file named `portable.txt` exists, all data is written to a `data/` folder next to the application instead of the per-user application data directory. That is the whole mechanism: no flag, no environment variable, just the presence of the file. If you want the portable layout, create it; if you do not, leave it absent and MrRSS writes to `%APPDATA%\MrRSS\` on Windows, `~/Library/Application Support/MrRSS/` on macOS, or `~/.local/share/MrRSS/` on Linux.

A first real use is adding a subscription. The README lists URL, XPath, script and newsletter feed types. Start with a plain URL, because it is the path with the fewest moving parts, and only reach for XPath or script extraction when a site has no feed of its own. AI translation and summarization are features of the app rather than commands, so there is no CLI invocation to show here; the README does not document the configuration keys for the AI provider.

Running the headless server and hitting the API

The desktop application exposes a REST API at `http://localhost:1234/api` while it is running, and the README notes the listener is restricted to the local computer. For a server deployment you use the headless build instead. The repository ships a `Dockerfile.server` and a compose file, and the compose service maps port 1234, mounts a named volume at `/app/data`, and sets `MRRSS_DEBUG=false`:

services:
  mrrss-server:
    build:
      context: .
      dockerfile: Dockerfile.server
    ports:
      - "1234:1234"
    volumes:
      - mrrss-data:/app/data
    environment:
      - MRRSS_DEBUG=false

Pre-built images are also published on ghcr.io under `ghcr.io/devxdojo/mrrss:latest-amd64` and `ghcr.io/devxdojo/mrrss:latest-arm64`, run with `docker run -d -p 1234:1234`:

docker run -d -p 1234:1234 ghcr.io/devxdojo/mrrss:latest-amd64
docker run -d -p 1234:1234 ghcr.io/devxdojo/mrrss:latest-arm64

The compose healthcheck polls `http://localhost:1234/api/version` every 30 seconds with three retries and a 40 second start period, which is a useful signal about how long the service takes to become ready on a cold volume.

Building the server without Docker uses a build tag, not a separate module:

go build -tags server -o mrrss-server .
./mrrss-server

The API reference lives at `docs/SERVER_MODE/swagger.json`, and a browser interface is documented separately. One caveat: the README's `docker run` example for a locally built image uses the tag `mrrss-server:latest`, which is not the same as the ghcr.io tags. If you build locally you supply your own tag.

Where MrRSS gets awkward

The build requirements are the first real cost. Source builds need Go 1.27 or higher, Node.js 20 LTS or higher, and the Wails v3 CLI, pinned in the README to `v3.0.0-alpha2.117`. The go.mod file declares `github.com/wailsapp/wails/v3 v3.0.0-beta.16`. Those two do not match, and an alpha or beta UI toolkit is a moving target: an upgrade can change build behaviour without a corresponding change in MrRSS itself. If you plan to build from source and keep building, budget for that.

Linux adds system dependencies that are not optional: GTK4, WebKitGTK 6.0, libsoup 3.0, GCC and pkg-config. The README gives the Ubuntu 24.04 install line, which means older distributions are on their own. This is a desktop app with a native webview, not an Electron bundle, so the platform libraries have to be present.

The third limitation is documentation of state. The README describes where data lives but does not describe schema migrations, rollback, or what happens when a newer version opens a database written by an older one. Releases arrive frequently, with v1.3.32, v1.3.33 and v1.3.34 landing within a week of each other in September 2026, so version-to-version data handling is not a hypothetical concern. Back up the data directory before upgrading, and treat the portable layout as the easier one to snapshot because everything is under `data/`.

Finally, the AI features are the headline but the README does not document which providers are supported or how to configure a key. Anyone evaluating MrRSS primarily for summarization should confirm that before installing.

How it compares with FreshRSS and RSSHub

FreshRSS is the closest functional alternative and appears in the README as an integration target rather than a competitor. The difference in approach is where the work happens. FreshRSS is a PHP web application you host, and reading happens in a browser; MrRSS is a Go desktop application with a webview front end, and the server build is a secondary mode. If your requirement is a feed reader several people log into, FreshRSS is the shape you want. If your requirement is a single reader with local storage and AI processing on the articles, MrRSS is built for that.

RSSHub solves a different problem entirely: it generates feeds for sites that do not publish them. MrRSS can consume RSSHub output, and the README lists RSSHub among the plugin integrations, but MrRSS also implements its own extraction through XPath and scripts. So the two overlap at the edges. A practical stack is RSSHub generating routes and MrRSS reading them, with the XPath support covering the sites you do not want to route through a separate service.

Against a plain reader such as any feed client built on gofeed, the difference is the surrounding pipeline: language detection, translation, summarization, and a scriptable filter layer. That pipeline is also the reason MrRSS is heavier to install and harder to upgrade than a reader that only parses XML.

Licence, maintenance and upgrade cost

MrRSS is GPL-3.0. For individual use that changes nothing. For anyone embedding it in a product, the copyleft terms apply to distributed derivative works, and the plugin ecosystem is worth thinking about in that light: plugins that link against the application may fall under the same terms. This is a description of the licence, not legal advice; if you plan to redistribute, read the LICENSE file and talk to someone qualified.

The repository is not archived, and the last push was on 2026-09-15, one day before this was written. Releases are frequent, with three tagged versions in the week before that push. Frequent releases are a mixed signal for adopters: fixes arrive quickly, and so does churn. The CHANGELOG.md file in the repository root is the place to check what moved between versions before you upgrade a working installation.

Upgrade cost concentrates in two places. The Wails v3 alpha pin means a source build can break on a toolkit bump rather than a MrRSS change. The SQLite database means data lives in a single file under the data directory, which makes backup trivial and migration risk concentrated: copy the directory before upgrading, and if the new version does not open the database, the copy is the rollback. The README does not document a rollback procedure, so that copy is the procedure.

Editorial conclusion

Adopt MrRSS if you want a desktop reader that summarizes and translates feeds locally, or a self-hosted instance you can reach from a browser on port 1234. Skip it if you need a stable, tagged Wails release or a documented upgrade path, because the README builds against a Wails v3 alpha and says nothing about migrating data between versions. Before committing, verify the AI provider settings, confirm the portable.txt behaviour puts data where you expect, and check whether the server image tag you plan to pin actually exists.

Frequently asked questions

Official sources

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