Model or dataset
miantiao-me/aigc-weekly avatar
miantiao-me/aigc-weekly

Agili's AIGC Weekly: a self-hosted Chinese AI newsletter run by an OpenCode agent

Agili 的 AIGC 周刊 - 一个由 Agentic AI Agent 驱动的 AIGC(人工智能生成内容)精选周刊。

563 stars66 forksTypeScriptAGPL-3.0

At a glance

What is it?
The repository behind aigc-weekly.agi.li splits into three parts: a Next.js and Payload CMS site, an OpenCode agent in a Cloudflare Container, and a Worker that starts and stops it. Here is what each piece does, how to run it locally, and where the design gets expensive.
Who is it for?
Adopt it if you already run Cloudflare Workers, D1 and R2 and you want an editorial pipeline where the agent writes into Payload through MCP rather than into a flat file. Skip it if you want a static Markdown newsletter, if you object to AGPL-3.0, or if you are not prepared to pay for Cloudflare Containers.
Can I use it commercially?
Yes, with strict conditions. AGPL-3.0 is a network copyleft licence: if people use a modified version over a network, for example as a hosted service, you must offer them its source code under the same licence.
Is it still maintained?
Yes. The repository last received commits 9 days ago.
What is it written in?
Mainly TypeScript, according to GitHub's language statistics.

Answers come from the project's GitHub data, last synced on September 29, 2026, and from our analysis. They are not legal advice.

Editorial analysis

What aigc-weekly actually is, and who it is built for

This is the source of a published Chinese-language weekly about AIGC, meaning AI-generated content. The live site is at aigc-weekly.agi.li and it also exposes an RSS feed at aigc-weekly.agi.li/rss.xml. The distinguishing claim in the README is that the curation is done by an Agentic AI Agent rather than by a person with a bookmark folder.

The intended user is not a newsletter reader. It is someone who wants to run the pipeline: an engineer comfortable with pnpm, Wrangler and Cloudflare bindings, who wants an agent to discover and filter items and then write them into a CMS that renders a public site. The repository is private in the package.json sense, version 0.1.0, so treat it as a working system rather than a released product. Anyone expecting a one-command install of a finished newsletter will be disappointed by how much of the setup is Cloudflare configuration.

Three components: Next.js, an OpenCode agent, and a Worker that wakes it

The README describes three components, and the repository layout matches. The app/ directory holds a Next.js App Router application that serves both the reader-facing pages and the Payload CMS admin interface. Collections and migrations live in collections/ and migrations/ at the top level, with payload.config.ts wiring them together.

The second component is the agent. It is an OpenCode service defined by agent/opencode.json and agent/.opencode/, and it runs on Cloudflare Containers. Its job is to collect information and update the CMS, and the README says it does that through MCP, the Model Context Protocol, so the agent talks to Payload as a tool rather than by editing files. This is the most interesting design decision in the project: the agent is not a script that emits Markdown, it is a client of the same CMS the editors use.

The third component is worker/, a Cloudflare Worker that forwards requests to the Container and controls its lifecycle. That is why an otherwise static-ish site needs a Worker at all. A Container is not always running, so something has to start it on demand and shut it down afterwards.

Storage is Cloudflare D1, a SQLite database, for content and Cloudflare R2 for object storage. The Dockerfile shows the Container image: a Python 3.12 and Node 22 base, OpenCode installed from the vendor install script, the agent configuration copied into /root/workspace, and opencode web started on port 2442.

Installing it and getting the admin panel up on localhost

The README lists Node.js v22 or higher and pnpm v10 or higher as prerequisites, plus a Cloudflare account for D1, R2 and Workers. Note that package.json pins packageManager to [email protected] while the README says pnpm v10, a small inconsistency worth knowing before a CI run fails on it.

Clone and install first:

bash
git clone https://github.com/miantiao-me/aigc-weekly.git
cd aigc-weekly
pnpm install

Then copy the two environment files. The root .env.example contains only PAYLOAD_SECRET and NEXT_PUBLIC_BASE_URL, and the README says to fill in the same pair for worker/.env.local.

bash
cp .env.example .env.local
cp worker/.env.example worker/.env.local

Before the app will build, the README says you must configure bindings in wrangler.jsonc: D1 for the database, R2 for object storage, and PAYLOAD_SECRET as a secure random string. Generate the Cloudflare and Payload types next, since the app imports them.

bash
pnpm generate:types

The agent needs a model and MCP configuration in agent/opencode.json, and the README points to agent/.opencode/ for skills, sub-agents and commands. Web crawling uses Firecrawl, and the README says to register there, get an API key, and set FIRECRAWL_API_KEY in worker/.env.local. Start the site:

bash
pnpm dev

The README says the app is then at http://localhost:3000 and the admin panel at http://localhost:3000/admin. To run the Worker and the agent together, use pnpm dev:worker, which the package.json defines as wrangler dev on port 2442 with a local persisted state directory. The README states that Docker is required for the local sandbox and that the Worker starts the OpenCode Agent container itself. Deployment is two commands, pnpm deploy for migrations and the OpenNext build, then pnpm deploy:worker.

The Cloudflare Containers dependency is the real cost

The README is direct about this: the agent runtime is Cloudflare Containers, and the parenthetical says it requires a paid plan, or you run it locally instead. That single line decides whether this project is viable for you. The Next.js app, Payload, D1 and R2 can sit on modest Cloudflare usage, but the agent needs a container runtime that is not part of the free tier.

There is a second consequence. Because the agent runs in a container behind a Worker, local development of the agent path needs Docker, and the README says so. If you only want the site and the CMS, pnpm dev is enough and you can ignore the agent entirely. If you want the curation loop, you are maintaining a container image, a Worker, and a CMS in one repository.

The crawling step adds an external dependency that the README does not route around. Firecrawl is named as the tool for web scraping and information extraction, and FIRECRAWL_API_KEY is required in worker/.env.local. The README does not document a fallback crawler, so an outage or a quota limit at that vendor stops discovery. It also does not document rollback for a bad curation run, which matters when an agent is writing directly into the CMS.

How this differs from static newsletter generators

The obvious alternative approach is a static site generator fed by Markdown, where each issue is a file committed to the repository and the build produces the pages. That model has no database, no admin UI, no container, and no vendor API key. Its weakness is exactly where aigc-weekly invests: an agent cannot easily write structured entries with relations, media in R2 and a reviewable draft state into a folder of Markdown without you inventing a convention for it.

Payload CMS is the pivot. By making the CMS the interface, the agent gets typed collections and an admin panel that a human can open at /admin to correct a bad summary. The trade is operational weight. You now run D1 migrations, which is why pnpm deploy is split into deploy:database and deploy:app, and you carry an AGPL-3.0 obligation that a private Markdown repository would not impose. For a solo writer publishing a link roundup, the static route is cheaper and the agent is optional. For someone who wants the curation itself automated and reviewable, the CMS-first design is the reason to pick this repository over a theme.

Licence and what an upgrade actually involves

The project is licensed under GNU Affero General Public License v3.0, stated in the README and present as LICENSE. AGPL-3.0 is a strong copyleft licence, and its network clause is the part to read carefully if you plan to run a modified version as a public service. That is a description of the licence, not legal advice; if the network clause affects your plans, ask a lawyer.

Upgrade cost is dominated by the stack rather than by the project's own code. Next.js 15 with OpenNext, Payload CMS 3.x, the Cloudflare D1 SQLite adapter, Wrangler and the Containers package all move independently, and package.json shows them as caret ranges, so a fresh pnpm install can pull newer minors than the ones the author ran. The repository ships migrations in migrations/ and a deploy:database script that runs payload migrate before the app build, which is the upgrade path for schema changes. Type generation is a separate step, pnpm generate:types, and it regenerates both cloudflare-env.d.ts and payload-types.ts, so it belongs in your upgrade routine. There are no retrieved releases, so there is no changelog to read between versions; you are tracking master.

Editorial conclusion

Adopt it if you already run Cloudflare Workers, D1 and R2 and you want an editorial pipeline where the agent writes into Payload through MCP rather than into a flat file. Skip it if you want a static Markdown newsletter, if you object to AGPL-3.0, or if you are not prepared to pay for Cloudflare Containers. Before you commit, verify two things: that your Cloudflare plan covers Containers, and that you have a Firecrawl API key for worker/.env.local, because the README names Firecrawl as the crawler and does not describe a fallback.

Frequently asked questions

What does AIGC mean in the name of aigc-weekly?

The README expands it as AI-generated content and describes the project as a curated weekly about it. The name therefore refers to the subject matter of the newsletter, not to a format the tool produces.

Can I run aigc-weekly without paying for Cloudflare Containers?

The README states that the Cloudflare Containers runtime needs a paid plan, or that you can run it locally instead. Running locally requires Docker, because the README says the Worker starts the OpenCode Agent container in a local sandbox.

What do I need besides a Cloudflare account to set up aigc-weekly?

Node.js v22 or higher and pnpm, a Cloudflare account for D1, R2 and Workers, and a Firecrawl account for the API key that goes into worker/.env.local. The README also requires D1 and R2 bindings plus PAYLOAD_SECRET in wrangler.jsonc.

How does the agent in aigc-weekly write content into the site?

Through MCP, the Model Context Protocol. The README says the Agent MCP integration lets the AI Agent interact directly with the CMS, and that the OpenCode agent collects information and updates the CMS this way.

What licence does aigc-weekly use?

GNU Affero General Public License v3.0, given in the README and included as LICENSE. The repository is public and the licence is copyleft, with the network clause that applies to running modified versions as a service.

Official sources

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

If you maintain this project, the badge below links readers to this analysis and shows its maintenance status from the daily GitHub snapshot. Paste the markdown into your README; add ?metric=license or ?metric=stars to the image URL for a different field.

Add this badge to your README

markdown
[![Hysen Labs](https://hysenlabs.com/badge/miantiao-me-aigc-weekly.svg)](https://hysenlabs.com/projects/miantiao-me-aigc-weekly)