Self-host an RSS reader or feed on Cloudflare

Three jobs hiding behind one search

People who search for a self-hosted RSS reader, feed or aggregator want one of three different things, and most roundups mix them:

• Read other people's feeds in one place. That is a feed reader.
• Publish your own feed: a blog, a podcast, a link list.
• Convert something that is not a feed, such as an email newsletter, into one.

We have reviewed one Cloudflare project for each job. Each links to its project page with the pinned README, license and configuration-derived architecture. The comparison below is about what each one's config declares, not about a deployment we ran.

Criterion	Larafeed	Microfeed	Cloudflare-Email-RSS
Job	Read feeds	Publish feeds	Turn newsletters into feeds
Is it a reader?	Yes	No	No, needs a separate reader
License	MIT	AGPL-3.0	MIT
Pinned commit	eedbc8b	bb84a81	64f541d
Declared bindings	D1, KV, Images, 3 queues	D1, R2, 1 queue	R2
Scheduled job	Cron every 10 minutes	Cron hourly	None
Needs a domain	Public HTTPS origin (asked by installer)	Not established	Yes, for Email Routing
What we ran	Nothing	Nothing	Original handler, locally, synthetic mail

Larafeed: the reader, and whether its config fits Cloudflare

The Larafeed README describes it as "a simple feed reader" and lists RSS, Atom, RDF and JSON Feed support, feed discovery from a website address, per-subscription filters, read, starred and archived entries, OPML import and export, and passkey-only private access. It also implements Google Reader and Fever APIs, which the README says are partial but work with Reeder Classic.

Whether it really targets Cloudflare is answered by wrangler.jsonc at commit eedbc8b. The file has a default scope plus separate production and vitest environments, and they differ:

• Default scope (larafeed-template): a Worker entry point, a DB binding to D1, a FULL_CONTENT_KV KV namespace, an IMAGES binding, three queue producers and three consumers (feed refresh, OPML import, favicon refresh), static assets served as a single-page app, and a cron of */10 * * * *. The database and KV IDs are all-zero placeholders, so you provision your own.
• No Workers AI binding in the default scope. The AI binding appears only under env.production, which also holds the author's own route and a five-minute cron. The default vars set AI_SUMMARY_ENABLED, IMAGES_ENABLED and FAVICON_REFRESH_ENABLED to false. The README advertises AI summaries through Workers AI and AI Gateway, so that is an optional extra with its own setup and cost, not part of the base reader.
• A required secret, AUTH_OPERATOR_SECRET, used to create the first administrator enrollment link.

So the base reader is Worker plus D1, KV and Queues, all Cloudflare services. The README's Deploy to Cloudflare button is described as provisioning the Worker, D1 database, KV namespace and queues and applying the migrations. We did not press it. The project page marks the architecture as configuration-derived, not tested.

Will the queue allowance hold your subscriptions?

The first limit to check on the Free plan is Queues: 10,000 operations a day, and delivering one message usually takes three (a write, a read and a delete). The Larafeed README says queues process feed refreshes one feed at a time. If each refresh is one message, the arithmetic is:

• 10,000 operations ÷ 3 ≈ 3,300 messages a day, or about 138 feed refreshes an hour, before favicon jobs, OPML imports and retries.
• The default REFRESH_DUE_LIMIT is 5. If that caps how many feeds the ten-minute cron queues per run (we did not read the code that applies it), the ceiling is 5 × 144 runs = 720 refreshes a day, about 2,160 queue operations.

This is our estimate from the config and Cloudflare's published numbers. The README also says refresh timing adapts to how often each feed changes, so real use could be lower. KV on the Free plan allows 1,000 writes a day, which matters if full-content caching writes for many entries. Measure both on a real deployment before relying on the free plan.

Microfeed: for publishing a feed, not reading one

Microfeed's README calls it a lightweight CMS self-hosted on Cloudflare that publishes audio, video, photos, documents, blog posts and links as web, RSS and JSON feeds. Use it if the question is "how do I host my own feed or podcast", not "how do I follow other feeds".

The root wrangler.jsonc declares a Worker, a D1 binding (FEED_DB), an R2 bucket binding for media (MEDIA_BUCKET), a webhook queue with a consumer, static assets and an hourly cron. It requires three secrets: UPLOAD_SIGNING_KEY, BETTER_AUTH_SECRET and WEBHOOK_SECRET_KEY.

Two cautions from our review notes. The file's own comment says yarn manage generates a complete per-installation config, and generated configs can omit R2 or the webhook queue and cron, so your instance may differ from the table above. And wrangler.template.jsonc contains placeholder tokens and does not parse as plain JSON, which our config analysis flagged. We scoped the diagram to the root file.

Media is the cost to watch: the R2 free allowance is 10 GB-month of Standard storage. It is AGPL-3.0, so read the AGPL license guide if you modify it and let others use your copy.

Cloudflare-Email-RSS: newsletters into a feed

Cloudflare-Email-RSS takes mail sent to an Email Routing address, writes one Atom file per sender into an R2 bucket and keeps an OPML list of all the feeds. Its README suggests pointing a self-hosted aggregator such as FreshRSS at that OPML. Its wrangler.jsonc declares only an R2 binding (RSS_BUCKET), with FEED_MAX_ENTRIES set to 20, optional Pushover notifications and no cron.

This is the only one of the three that we ran, and only in part. On 2026-10-03 we pushed two synthetic messages through the unchanged original email handler with an isolated local R2 bucket:

• The output was well-formed Atom with both entries, newest first.
• The OPML held one subscription after two messages from the same sender.
• All seven upstream tests passed, with outbound networking mocked.

We did not test real Email Routing, public bucket access, compatibility with any RSS reader, real push notifications, production deployment or billing. The README asks for a Cloudflare-managed domain and a public R2 bucket protected by security rules, so decide who should be able to fetch your newsletter feeds before you publish the bucket. Inbound Email Routing is available on the Free plan, but the Worker that processes each message uses Workers quota.

Picking one, or combining two

• You want a private place to read feeds: Larafeed. Check the queue maths above against your subscription count.
• You want to publish a blog or podcast feed: Microfeed.
• You want newsletters out of your inbox and in your reader: Cloudflare-Email-RSS, plus a reader.

Larafeed reads RSS and Atom and imports OPML, and Cloudflare-Email-RSS writes Atom and OPML, so the two should fit together on paper. We have not tried it. If you already run a Docker host, readers that are not built for Cloudflare, such as FreshRSS and Miniflux, are the established alternatives (Larafeed's README credits both); we have not reviewed them here.

For the wider picture of what these projects map to, see the Feedly and Inoreader alternatives pages, and the Kill the Newsletter page for the email case. A different Cloudflare-only pattern, with a similar structure, is in the self-hosted bookmark manager guide.

Checklist before you rely on one

1. Deploy to a workers.dev address first, with your own D1, KV, R2 and queue IDs, and apply every migration.
2. For Larafeed, import a small OPML file, then watch queue operations in the dashboard for a day before adding the rest.
3. Decide on purpose whether a feed or bucket is public. Test it from a private window.
4. Back up your OPML export and database. Check the MIT or AGPL terms if you change the code.
5. Set Cloudflare billing notifications, as the Email-RSS README itself recommends.