aigc-weekly: an AI agent that edits a Payload CMS on Cloudflare

The problem: curation is the expensive part of a weekly

A weekly newsletter is mostly a filtering job. Someone reads feeds, opens links, decides what is worth a paragraph, and then formats it. The publishing half is solved by any CMS. The repository takes the position that the filtering half can be handed to an agent, and it ships the whole loop: discovery, extraction, selection, and a write into the CMS. The audience is narrow and identifiable. It is for developers who already accept that an LLM will make editorial choices on their behalf and who want to see the plumbing that makes that safe enough to run on a schedule. It is not aimed at writers who want a nicer static site generator. The README frames the project as "由 Agentic AI Agent 驱动" (driven by an agentic AI agent), and the rest of the repository is the machinery behind that claim.

Three processes, one repository

The README splits the project into three components, and the split is the most informative thing in the document. First, the Next.js app under app/ serves both the reader-facing pages and the Payload CMS admin UI. Second, the OpenCode agent under agent/ runs as a separate service on Cloudflare Containers and is the part that gathers information and updates the CMS through MCP. Third, a Cloudflare Worker under worker/ forwards requests to the container and manages its lifecycle. That third piece is the tell. If the agent were cheap to run, it would be a function. Instead it is a container behind a Worker, which means the Worker exists mainly to start, route to, and stop a long-lived process. Data flows one way for readers (D1 and R2 through the Next.js app) and one way for the agent (MCP calls into Payload, which writes to the same D1 database). The agent never renders anything. It only mutates content.

MCP is the boundary that makes this debuggable

The choice to have the agent talk to Payload through the Model Context Protocol rather than through a bespoke HTTP client is the design decision worth copying. It means the agent's available actions are declared as tools, and the tool surface is what you audit when you want to know what the agent can change. The README lists MCP integration as a feature and points at agent/opencode.json for MCP server and model configuration, with agent/.opencode/ holding skills, sub-agents and commands. That is a real separation: the model and its tool list live in configuration, not in application code. It also creates the main operational question. Whatever the agent can do through those tools, it can do without a human in the loop. The repository does not document a review queue or a draft state in the README, so if you need an approval step before publication, plan to build it into the Payload collections yourself.

Getting it running: the commands the README gives

Prerequisites are Node.js v22 or higher, pnpm v10 or higher, and a Cloudflare account for D1, R2 and Workers. Clone the repository, then run pnpm install. Configuration is two environment files: copy .env.example to .env.local, and copy worker/.env.example to worker/.env.local. The README states you must configure bindings in wrangler.jsonc for D1, R2 and PAYLOAD_SECRET, the last being a random string. Then run pnpm generate:types to produce Payload types. Web scraping uses Firecrawl, so you register an account, obtain an API key, and set FIRECRAWL_API_KEY in worker/.env.local. Local development is two terminals: pnpm dev serves the app on http://localhost:3000 with the admin at http://localhost:3000/admin, and pnpm dev:worker starts the Worker plus the agent container. The README notes Docker is required for the local sandbox and that the Worker starts the OpenCode container automatically. Deployment is pnpm deploy, which runs deploy:database for migrations and deploy:app for the OpenNext build and upload, followed by pnpm deploy:worker.

The container dependency is the real cost

Cloudflare Containers is listed in the tech stack with the parenthetical that it requires a paid plan, or you run locally instead. That single line shapes the whole adoption decision. There is no free-tier path to a hosted agent here. If you are evaluating the project on a hobby budget, you are limited to pnpm dev:worker on your own machine with Docker installed, which is fine for reading the code and useless as a newsletter that updates while you sleep. There is a second constraint in the same area. Firecrawl is an external service with its own account and key, so the extraction step depends on a third party the project does not control. A failure there is not a bug in this repository, but it will look like one when the agent returns nothing to curate. Neither of these is hidden, but neither is it framed as a limitation in the README, and both should be read as operating costs rather than setup friction.

Where it is the wrong tool

If your newsletter is a hand-picked list of five links a week, this project is more machinery than the job needs. You would be running a Next.js app, a Payload instance, a D1 database, an R2 bucket, a Worker, and a container, all so an agent can do something you were going to do in twenty minutes. The same applies if your content requires judgement the agent cannot verify: anything involving embargoed material, private sources, or claims that need a phone call. The architecture gives the agent write access to the CMS through MCP tools. There is no described mechanism in the README for the agent to flag uncertainty rather than publish. For a personal link blog, a static site generator plus a markdown file is the honest comparison, and it wins on every axis except automation. This project is worth its complexity only when the volume of candidate material is large enough that filtering, not writing, is the bottleneck.

The alternative: a scheduled script that opens a pull request

The closest conventional approach is a cron job that fetches feeds, asks a model to rank items, and opens a pull request against a content repository. The difference is where the judgement lands. In that pattern the model produces a proposal, a human merges it, and the published artifact is a file in git with a reviewable diff. Here the agent holds MCP tools that write to Payload, so the reviewable artifact is a database row, and the review step is whatever the CMS collections happen to enforce. That is not worse, it is a different trade. The pull request pattern gives you history and rollback for free and caps the blast radius at a branch. The aigc-weekly pattern gives you structured content, media in R2, and a queryable database, at the cost of building your own guardrails. If your team already lives in Payload and Cloudflare, the second pattern fits. If your team lives in git, the first one will be less work to operate.

Licence and the maintenance you inherit

The project is AGPL-3.0. That matters more than usual for a web application, because the licence's network clause reaches software offered to users over a network. If you deploy a modified version as a public newsletter, the obligations attach to the running service, not just to distributed binaries. This is not legal advice; if you plan to modify and host it commercially, have someone read the licence text rather than a summary. On maintenance, the repository is active and the last push is recent, but there are no retrieved releases, so there is no tagged version to pin against. Upgrades are therefore a matter of tracking master. The stack is also version-sensitive in a way that raises the cost of falling behind: Next.js 15 with OpenNext, Payload CMS 3.0, and Cloudflare Containers are all moving parts, and the Worker, the container image, and the app must stay compatible with each other. Budget for reading diffs in wrangler.jsonc and the migrations directory, not for a version bump command.

Editorial conclusion

Adopt it if you want a concrete template for an agent that writes into a headless CMS on Cloudflare's stack, and you are willing to run Cloudflare Containers on a paid plan or locally with Docker. Do not adopt it if you want a static newsletter site with no agent runtime, or if AGPL-3.0 obligations do not fit how you plan to host a modified version. Before committing, verify the bindings named in wrangler.jsonc (D1, R2, PAYLOAD_SECRET), confirm your Firecrawl key is set as FIRECRAWL_API_KEY in worker/.env.local, and read agent/opencode.json to see which model and MCP servers the agent will actually call.

Official sources

1. Issues
2. License: AGPL-3.0
3. miantiao-me/aigc-weekly on GitHub
4. Project website
5. README