microfeed: a Cloudflare-hosted CMS for feeds, podcasts and agent-managed content

What microfeed solves, and for whom

microfeed targets a narrow but real problem: publishing a feed of items (audio episodes, blog posts, photos, videos, documents, curated external URLs) without renting or administering a server. The README frames the history plainly, noting that a significant portion of the web has been powered by feeds since the 1990s, and that microfeed lets an individual self-host one. The intended user is the tech-savvy individual rather than a media organisation: the project says it is for people who want to self-host a CMS without running their own servers. It is built by Listen Notes and hosted on Cloudflare Workers, R2 and D1. The README lists concrete deployments, including a podcast-style feed at llamacorn.listennotes.com, a brand asset gallery, a book site for The Art of War, and a changelog. Those examples are useful because they show the same engine pointed at very different content shapes. What they do not show is editorial workflow at scale, and the README does not claim any.

Workers, R2 and D1: the mechanism behind a microfeed site

The architecture is three Cloudflare services with distinct jobs. Workers host and run the application code. R2 stores and serves media files. D1 stores metadata. Authentication is a built-in email and password login that protects the admin dashboard, so there is no external identity provider in the default path. Each published item is rendered three ways: a web feed, an RSS feed and a JSON feed, which is why the README describes the same content as a podcast feed, a blog feed, an image feed or a curation feed depending on what you put in it. The repository layout matches that split: src/ holds the Worker and Astro application code, migrations/ holds D1 schema migrations, themes/ holds theme workspaces, and wrangler.jsonc is the deployment configuration. The README also describes themes as immutable, D1-backed versions, with isolated Admin drafts and previews, and installation through npx @microfeed/cli manage theme. That versioning design is the most interesting part of the stack: it means a theme change is a stored revision rather than an in-place file edit, which is a meaningfully different model from editing template files on a server.

Installing microfeed with the CLI and publishing a first item

The README's quickstart is aimed at a local AI coding agent such as OpenAI Codex, Claude Code or Cursor, one that can run terminal commands and open a browser. You give the agent this prompt, and it drives the rest of the setup. The launcher requires Node.js 22.12 or newer with npm, carries the exact microfeed release and Yarn runtime, verifies and copies that source into a private cache, and installs locked dependencies without Git or Corepack. The README states the first setup may use about 1.3 GB and take several minutes, and that later runs reuse the cache. It also states the launcher does not create source files in your current folder.

Deploy microfeed to Cloudflare. Start by running `npx @microfeed/cli manage`,
then follow its instructions until deployment is verified.

If you prefer to run the launcher yourself rather than through an agent, the same entry point is available directly. Run it from any folder. The README notes that if you have Git-cloned the source repository and installed its dependencies, yarn microfeed is a shortcut that runs the repository's local CLI version instead of the published one.

npx @microfeed/cli manage

Once the site is deployed, publishing happens either in the built-in admin dashboard or through the CLI for agentic content management. The README states the CLI can create, update and delete items and upload media files such as images, audios, videos and documents. The dashboard is described as familiar to anyone who has used WordPress: you create and edit posts, upload media, and customise how the site looks. For a headless setup, the README points at the public demo's interactive API documentation, its OpenAPI JSON and YAML, and agent-ready llms.txt and llms-full.txt files. It also mentions credential-free typeahead search bound to Command or Ctrl-K, and editable generated robots.txt, llms.txt and sitemap.xml files.

Where microfeed stops being the right tool

The dependency on Cloudflare is total, not incidental. Workers, R2 and D1 are named as the runtime, the media store and the metadata store, and the repository ships a wrangler.jsonc plus a wrangler.template.jsonc for that platform. There is no documented path to run the same code on a VPS, on another edge provider, or against PostgreSQL. If your organisation already standardises on a different cloud, or if procurement rules forbid a single-vendor edge stack, microfeed is the wrong starting point. The D1 choice carries its own constraint: D1 is Cloudflare's SQL database, and the repository keeps schema changes in migrations/ applied through Wrangler, so schema evolution is tied to that toolchain. The README does not document a rollback procedure for a failed migration, and the project does not describe what happens to in-flight requests during a deployment. Cost is another boundary that is easy to misread. The README says Cloudflare provides very generous free usage quotas and that hosting microfeed is essentially free, while you still pay for a domain name. Free quotas are quotas, not guarantees; the README does not state what happens when a site exceeds them.

microfeed against a Node-based CMS like SonicJS

The nearest comparison in the search data is SonicJS, and the difference is architectural rather than cosmetic. SonicJS is a TypeScript CMS that runs on Cloudflare Workers too, but it is built around a conventional database layer and a broader content-modelling surface. microfeed's organising abstraction is the feed item: you publish audios, videos, photos, documents, blog posts and external URLs into a web, RSS and JSON feed, and the site is a view over that feed. That is why the README can describe the same installation as a podcast, an Instagram-like gallery, a YouTube-like video feed, a book site or a link list. If your requirement is a general-purpose content model with arbitrary types and relations, a feed-first CMS will feel like a constraint. If your requirement is to publish episodes or posts that must also exist as valid RSS and JSON Feed documents, the feed-first design is the point, not a limitation. The same reasoning separates microfeed from static-site generators: those produce files you deploy, whereas microfeed stores items in D1 and renders them on request.

Maintenance, releases and the AGPL-3.0 licence

microfeed is not archived, and the last push was on 2026-08-27, so the project is being changed rather than frozen. The release cadence visible in the release list is tight: v1.0.5 on 2026-08-19 added webhooks and content automation, v1.0.6 on 2026-08-27 reworked deployment and themes, and v1.0.7 on 2026-08-27 addressed remote theme workflows. The root package.json declares version 1.0.11, which is ahead of the newest release tag listed, so the repository and the tagged releases are not perfectly in step; treat the tag list as the stable surface and the branch as the moving one. Upgrade cost is concentrated in two places. First, D1 migrations under migrations/, applied with Wrangler, which is where a schema change would force a decision. Second, theme versions, which the README describes as immutable and D1-backed, so a theme update is a new stored revision rather than an edit to files on disk. The licence is AGPL-3.0, declared in both package.json and the repository's LICENSE file. AGPL-3.0 is a copyleft licence with a network clause: if you run modified microfeed as a network service, the licence's source-availability obligations can attach to your users. That is a real consideration for anyone embedding it in a commercial offering, and it is not a question this article can answer for your situation.

Editorial conclusion

Adopt microfeed if you want a personal or small-business feed, are comfortable with Cloudflare's free quotas and the Workers/R2/D1 stack, and can accept AGPL-3.0 obligations on a publicly reachable deployment. Do not adopt it if you need a conventional relational database, a large plugin ecosystem, or a host other than Cloudflare. Before committing, verify the current Node.js requirement (the package declares 22.12 or newer) and read the AGPL-3.0 terms with your own counsel, because the network-copyleft clause is the part that most often surprises teams embedding a CMS into a commercial product.

Frequently asked questions

Official sources

1. Official documentation
2. Official README
3. Project repository
4. Release notes