Fusion: a self-hosted RSS reader with a Fever API and no AI features

The problem Fusion targets: a reader you can back up with cp

Most hosted RSS readers treat your subscription list as their asset. Self-hosted alternatives exist, but a number of them arrive with a database server, a queue, a worker process, and a container orchestration file before you have read a single article. Fusion's README positions the project against that: it calls itself a lightweight RSS reader and lists self-hosting friendly as a feature, with deployment described as either a single binary or Docker. The intended user is someone running a home server or a small VPS who wants unread tracking, bookmarks, search, and keyboard-driven reading without operating a stack. The README also states a deliberate constraint that doubles as positioning: no AI features by design. For a reader, that is a scoping decision rather than a missing feature. It means the project's surface area stays at feed parsing, storage, and a web UI, and the release cadence stays in the range the repository shows, with v1.2.1 published in July 2026 after v1.2.0 two weeks earlier and v1.1.1 roughly five months before that.

How Fusion is put together: Go server, TypeScript frontend, SQLite file

The repository is labelled TypeScript, but the README's development section lists Go 1.25+ and Node.js 24+ with pnpm, and the build script is invoked as ./scripts.sh build. That combination points to a Go backend serving a compiled TypeScript frontend, which is consistent with the project shipping platform binaries in Releases and with the presence of fly.toml for Fly.io deployment. Feed parsing is delegated: the credits section names gofeed, the Go library, as the component that powers it. Persistence is a single database file, addressed by FUSION_DB_PATH, and the Docker examples mount a host directory at /data, so in practice the container writes its state into ./data or ./fusion on the host. The documentation set is more structured than the README alone suggests: docs/backend-design.md and docs/frontend-design.md describe each half, docs/openapi.yaml is the API contract, and docs/fever-api.md covers the compatibility layer. There is also docs/old-database-schema.md, kept, per the README, for migration work, which implies the storage schema has changed at least once and that upgrades across that boundary are a thing users have had to handle.

Running it: one environment variable, then a port

The README's recommended path is the pre-built binary. On Linux or macOS that is chmod +x fusion followed by FUSION_PASSWORD="fusion" ./fusion, and on Windows it is setting $env:FUSION_PASSWORD and running .\fusion.exe. The server then listens on http://localhost:8080. The Docker path is a single docker run with -p 8080:8080, a volume mount for /data, and the same FUSION_PASSWORD variable, against the image ghcr.io/0x2e/fusion:latest. The README distinguishes latest from main: latest tracks the most recent release, main is the development build. A Compose example is included and binds the port to 127.0.0.1:8080 rather than all interfaces, which is the safer default if you are not putting a proxy in front. Configuration beyond the password is grouped by intent. Running locally adds FUSION_PORT and FUSION_DB_PATH. Sitting behind a reverse proxy adds FUSION_CORS_ALLOWED_ORIGINS and FUSION_TRUSTED_PROXIES. Mobile clients add FUSION_FEVER_USERNAME, which defaults to fusion. SSO adds the FUSION_OIDC_* variables, with FUSION_OIDC_REDIRECT_URI set to https://<host>/api/oidc/callback, and the README notes that https://<host>/oidc/callback is accepted for compatibility. Feed pulling is tuned with FUSION_PULL_INTERVAL, FUSION_PULL_TIMEOUT, FUSION_PULL_CONCURRENCY, and FUSION_PULL_MAX_BACKOFF. Fetching from private network addresses requires FUSION_ALLOW_PRIVATE_FEEDS, which is off unless you turn it on. Legacy names DB, PASSWORD, and PORT still work. One option deserves a second look: FUSION_ALLOW_EMPTY_PASSWORD=true disables authentication entirely, and the README scopes it to local trusted environments when OIDC is also disabled. That is a footgun in a container that someone later exposes through a tunnel.

Fever API compatibility is the feature that decides the client question

Fusion's web UI is one option for reading; the Fever API is the other. The README lists compatibility with Reeder, Unread, and FeedMe, and points to docs/fever-api.md for the guide. Fever is a Google Reader era sync protocol, and the practical consequence is that you keep whatever client you already paid for and point it at your own server instead of a subscription service. The username comes from FUSION_FEVER_USERNAME and defaults to fusion; the password side is the same FUSION_PASSWORD used for the web login, since the README does not describe a separate Fever credential. Anyone exposing that endpoint should treat it as an internet-facing login form with a single shared secret and no second factor, which is why the Compose example's 127.0.0.1 binding matters. The web UI itself is described as responsive with PWA support, so the browser path is not a fallback for mobile. The README claims Google Reader-style keyboard shortcuts for the reading workflow, alongside unread tracking, bookmarks, and search.

Where Fusion is the wrong tool

Fusion is single-tenant in everything the README shows. There is one password, one Fever username, one database path. If two people in a household want separate unread counts and separate bookmarks, the documented configuration does not give you that; you would run two instances with two data directories and two ports, and accept that feed fetching happens twice. The authentication model is also thin. Password-only login is the default, OIDC exists as an alternative, and the only way to remove authentication is to set FUSION_ALLOW_EMPTY_PASSWORD=true, which the README restricts to local trusted environments. There is no documented role system, no read-only account for sharing a feed list, and no per-feed access control. The single-file database is a strength for backup and a limit for scale: the README gives no replication story, and since the project keeps an old-database-schema document for migration work, running an upgrade without a copy of the database file first is a self-inflicted risk. Finally, the no-AI stance is a boundary, not a bug. If you want automatic summarisation or semantic search over your archive, Fusion is not going to grow that, and the README says so on purpose.

FreshRSS and Miniflux take different positions on the same problem

Miniflux is the closest comparison and the sharpest contrast. It is also a self-hosted reader with a Fever-compatible API, but it is written in Go with a Postgres backend, which means adopting it starts with provisioning a database server and managing its backups and upgrades separately from the application. Fusion collapses that into one file and one process. The trade is that Miniflux's Postgres foundation supports patterns Fusion's SQLite file does not, and its operational surface is larger in exchange. FreshRSS sits at the other end: PHP, a web server, MySQL or PostgreSQL or SQLite, and a plugin ecosystem with themes and extensions. If you need to modify feed behaviour in ways the upstream project has not shipped, FreshRSS gives you hooks; Fusion's extension story is not described in the README beyond the API contract in docs/openapi.yaml. The honest framing is that Fusion competes on deployment friction, not on feature breadth. It is the option you pick when the deciding factor is that the whole application is one executable and one file on disk.

Upgrades, licence, and what to check before you rely on it

Fusion is MIT licensed, which permits commercial and private use, modification, and redistribution provided the copyright notice and permission notice are preserved. That is a permissive licence with no copyleft obligation on your own code, and it is the same licence Miniflux uses. It says nothing about the licence of the feed content you store, which is a separate question. On maintenance cost, the repository shows three releases across roughly thirteen months with the most recent push in August 2026, so the project is active but not fast-moving, and the presence of FUSION_PULL_MAX_BACKOFF in the configuration suggests the maintainers have thought about misbehaving feeds rather than assuming every server responds promptly. Upgrading means replacing a binary or pulling a new image tag, but the data directory is the part that carries risk: back up whatever FUSION_DB_PATH resolves to before changing versions, particularly if you are crossing a schema change of the kind docs/old-database-schema.md exists to document. The README does not describe an automatic migration path or a rollback procedure, so treat the database file as the thing you protect. For a reader holding years of bookmarks, that file is the only copy.

Who should run Fusion

The fit is a single person or a small group sharing one reading list on hardware they control, who wants the Fever protocol so an existing iOS or Android client keeps working, and who values being able to move the whole application by copying one directory. The mismatch is anyone who needs multiple isolated accounts, an enterprise identity setup where OIDC is mandatory rather than optional, or a database they can query and replicate with standard tooling. The middle case, a shared instance with a reverse proxy, is supported but demands care: set FUSION_TRUSTED_PROXIES and FUSION_CORS_ALLOWED_ORIGINS deliberately, never leave FUSION_ALLOW_EMPTY_PASSWORD=true on a host reachable from outside, and confirm your Fever client logs in with the name in FUSION_FEVER_USERNAME. None of those checks take long, and each one maps to a variable the README names.

Editorial conclusion

Adopt Fusion if you want a single-binary or single-container reader on a home server, you already own a Fever-compatible client such as Reeder or Unread, and you are comfortable with FUSION_PASSWORD as the only gate in front of your reading list. Do not adopt it if you need per-user accounts, OAuth-only login without an external identity provider, or a reader that stores articles in Postgres. Before committing, verify three things against the release you download: that FUSION_DB_PATH points where your backup job expects it, that your reverse proxy forwards the headers FUSION_TRUSTED_PROXIES is configured for, and that your Fever client authenticates against FUSION_FEVER_USERNAME rather than a username you assumed.

Official sources

1. 0x2E/fusion on GitHub
2. Issues
3. License: MIT
4. README
5. Releases