CommaFeed: A Java RSS Reader for People Who Want the Google Reader API Back

The Gap CommaFeed Fills: Your Server, Your Sync Protocol

The Google Reader shutdown pushed a lot of people onto hosted readers, and the ones that survived mostly sync through their own proprietary APIs. That is fine until you want to use a native mobile app that was written against the Google Reader API and has no intention of adding a second backend. CommaFeed exists in that gap. The README lists both Fever and Google Reader API support, which means the server implements the endpoints those clients already call. You are not choosing between a good web interface and a good phone app. You are running one server that answers to both. The target user is someone who already self-hosts something, is comfortable with a database URL and a properties file, and has a specific mobile client in mind. It is not aimed at the person who wants to sign up somewhere and be reading feeds in ninety seconds, even though the project does run a public instance at commafeed.com for exactly that case.

Quarkus Backend, React Frontend, and Where the Work Actually Happens

The stack is Quarkus on the server and React with TypeScript in the browser, packaged as a single application. The server does the feed fetching, storage, and article state, and exposes that through a REST API. The README also mentions a browser extension as a separate repository, which tells you the web app is not the only client surface the project cares about. Article state is not purely manual: the README states CommaFeed can automatically mark articles as read based on user-defined rules, and it can push notifications when new articles are published. The database layer is abstracted behind Quarkus datasource configuration, and the project supports H2, PostgreSQL, MySQL and MariaDB. That last point matters more than it looks. H2 is embedded and needs no configuration at all, so a first run works out of the box, but the same code path has to hold up against four different SQL dialects. If you are running MySQL or MariaDB, note that the README's example JDBC URLs carry connection parameters like autoReconnect, failOverReadOnly, maxReconnects, rewriteBatchedStatements and timezone=UTC. Those are not decorative. They are the project telling you which driver behaviours it expects.

Getting It Running: Docker, Native Binaries, or a JVM Zip

Docker is described as the easiest path, with images published to Docker Hub under athou/commafeed. If you would rather not use a container, the release page offers two package types. The linux-x86_64, linux-aarch_64 and windows-x86_64 packages are compiled natively and contain an executable you run directly. The jvm package is a zip of jar files that works everywhere but needs a JRE and is started with java -jar quarkus-run.jar. The README recommends the native package where available, citing faster startup and lower memory use. Building from source is a Maven wrapper command: ./mvnw clean package [-P<database> [-Pnative]] [-DskipTests]. The database profile is one of h2, postgresql, mysql or mariadb, defaulting to h2. The native profile needs either GraalVM with GRAALVM_HOME set or a container runtime available. Output lands in commafeed-server/target/, either as commafeed-<version>-<database>-jvm.zip or as a platform-specific runner binary. Configuration can come from config/application.properties, from command line arguments prefixed with -D, from environment variables in UPPER_CASE, or from a .env file. The README recommends the properties file because CommaFeed can then warn about invalid properties and typos, which is a small detail that saves real debugging time. The server listens on http://localhost:8082 by default.

The Session Encryption Key Is the Setting Everyone Forgets

Here is the sharpest operational detail in the README. Credentials are stored in an encrypted cookie, and the encryption key is randomly generated at startup. The consequence is stated plainly: you have to log back in after each restart. The fix is to set quarkus.http.auth.session.encryption-key to a fixed value of at least 16 characters. If you deploy CommaFeed behind a restart-on-deploy pipeline and skip that property, every deploy logs out every user, and you will spend an afternoon blaming the reverse proxy. This is a good example of a design choice that is defensible for a hobby instance and annoying for anything with more than one user. The README does not hide it, but it is the kind of line people skim past. Set it before you invite anyone else onto the instance.

Memory Behaviour and Why the Native Build Is Not Just Marketing

The README devotes a section to JVM memory, and it is honest about the problem: the JVM is greedy by default and will not release unused memory back to the operating system, because acquiring memory from the OS is expensive. On a small VPS this shows up as a process that grows and never shrinks. Two remedies are given. For both native and jvm packages you can cap the heap with -Xmx, for example -Xmx256m. For the jvm package specifically, the README suggests a longer set of flags: -Xms20m -XX:+UseG1GC -XX:+UseStringDeduplication -XX:-ShrinkHeapInSteps -XX:G1PeriodicGCInterval=10000 -XX:-G1PeriodicGCInvokesConcurrent -XX:MinHeapFreeRatio=5 -XX:MaxHeapFreeRatio=10. OpenJ9 is mentioned as a further option for the jvm package. This is where the native build earns its recommendation. A GraalVM native image sidesteps the whole heap-return problem, and the README frames native compilation as faster startup and lower memory usage rather than a speed claim about feed parsing. If you are running on a 512MB container, the native binary is the intended answer.

Where CommaFeed Is the Wrong Choice

The public instance has limitations compared to self-hosting, and the README points to a GitHub discussion rather than listing them, so anyone planning to rely on commafeed.com should read that thread before migrating a large subscription list. More broadly, CommaFeed is a single-maintainer project. The release cadence visible in the material is rapid, with 7.3.0, 7.3.1 and 7.3.2 all landing within about two weeks in August 2026, and the repository is not archived. Fast releases are not the same as a large contributor base, and nothing in the supplied material establishes how many people work on it. If your organisation requires a vendor to call, this is not that. There is also the protocol question. Google Reader API support means implementing an API that Google itself retired. It works because client authors kept calling those endpoints, not because anyone is maintaining the specification. If a future client drops Google Reader support in favour of something newer, CommaFeed has to add that too, and the project's ability to do so depends on one maintainer's time. Finally, if you want a reader with a managed sync service, cross-device read state without running a database, and no upgrade windows, CommaFeed is simply the wrong shape of tool.

Alternatives and the Actual Difference in Approach

The obvious comparison is Miniflux, another self-hosted reader that runs as a single Go binary against PostgreSQL. The difference is architectural, not cosmetic. Miniflux is one process with one required database and its own REST API, and third-party clients are written against that API. CommaFeed runs on the JVM or as a GraalVM native image, supports four databases including an embedded one, and its client story leans on reimplementing APIs that existing apps already speak. That means CommaFeed can be adopted by someone who already has a favourite Google Reader client and does not want to change it, while Miniflux asks you to pick from its own client ecosystem. The trade is that Miniflux's client surface is defined by a project that is still developing it, and CommaFeed's is defined by a protocol frozen in 2013. Neither is strictly better. If you have no attachment to an existing mobile app, the protocol argument for CommaFeed mostly evaporates, and the simpler deployment model of a single Go binary becomes more attractive. If you do have that attachment, CommaFeed is one of the few self-hosted options that will not force you to abandon it.

Licence, Upgrades, and What to Verify Before You Commit

CommaFeed is Apache-2.0, which permits commercial use and modification, and includes a patent grant. That is a permissive licence with no copyleft obligation on your own code, though as always the terms govern and this is not legal advice. Upgrades are straightforward in principle: the README suggests subscribing to the releases Atom feed to be notified of new versions, and Docker images are built automatically. Three releases in roughly two weeks in August 2026 means you should expect to upgrade with some frequency if you want fixes, and you should pin a version rather than tracking latest if you care about stability. Two things are worth verifying on your own instance before you commit. First, confirm which package type you actually need by checking whether a native build exists for your platform and architecture, since the jvm zip is the fallback and it carries the memory-tuning burden described above. Second, confirm your chosen database against the JDBC URL examples in the README, because the MySQL and MariaDB URLs include specific driver parameters that the project expects to be present. Get those two right and the rest of the configuration is optional, with sensible defaults.

Editorial conclusion

Adopt CommaFeed if you want one server that feeds both a browser UI and existing native mobile clients through the Google Reader or Fever API, and you are willing to run Java or a native binary plus a database. Skip it if you want a hosted service with zero operations, or if you need a reader whose sync protocol is actively maintained by a large ecosystem rather than reimplemented by one project. Before committing, verify the encryption-key behaviour: set quarkus.http.auth.session.encryption-key to a fixed value of at least 16 characters, otherwise every restart of the application logs you out again.

Official sources

1. Athou/commafeed on GitHub
2. License: Apache-2.0
3. Project website
4. README
5. Releases