Payload CMS vs. a git-based blog: what we chose for an agent-written site

This journal is written and translated largely by AI agents, with humans reviewing every change. That constraint — agents as the primary authors — turns the classic "which CMS?" question on its head. Before building it, we did a proper evaluation of Payload CMS against the boring alternative: content files in the repo. Here is what we found, as of June 2026.

Payload 3 in 2026: genuinely good, newly complicated

Payload 3.x is the current line (3.85 shipped days before this post) and it is Next.js-native: the admin panel and the REST/GraphQL APIs install into a Next.js app. For a team that wants a real editorial UI — drafts, scheduled publishing, non-technical editors — it remains one of the best open-source options.

Three findings mattered for us:

• It can run on Cloudflare now. There is an official with-cloudflare-d1 template that deploys via OpenNext on Workers, with D1 for the database and R2 for media. But the D1 adapter (@payloadcms/db-d1-sqlite) is explicitly beta, the bundle needs the paid Workers plan, and GraphQL is not guaranteed on workerd — REST only.
• Localization is first-class. Field-level localized: true, configurable fallback locales, and a REST API that accepts ?locale=all — which returns every locale keyed by code, exactly what a translation agent wants for diffing.
• Figma acquired Payload. The open-source core continues, but Payload Cloud is paused for new deployments. Self-hosting is the only realistic path, and the roadmap carries acquisition-era uncertainty.

The agentic test: who edits this content, and how?

The deciding question wasn't features — it was workflow. An AI agent's native skill is editing files and opening pull requests. Put content behind a CMS API and the agent needs credentials, schema awareness, and a custom review surface. Put content in the repo and the agent uses the exact tooling it already has, and the review gate is the one your team already trusts: code review.

A CMS earns its infrastructure cost the day a non-technical human needs a WYSIWYG admin. Until then, git is the better content database.

For an agent-maintained site, git-based content wins on every axis we scored:

• Authoring: agents write typed TSX/MDX files; the compiler and CI validate structure — no malformed rich-text JSON.
• Review: every article and every translation is a diff in a PR.
• Rollback and history: git, for free.
• Infra: zero. No second deployable, no beta database adapter, no admin panel to secure.

Where Payload would still win

We'd reach for Payload the moment marketing hires a non-engineer editor, or when content needs scheduling, embargoes, or a media library with image renditions. The migration path is clean: our posts are typed objects, and Payload collections are typed schemas — a one-time import script. If you're on that path today, the pipeline that works is: afterChange hooks queueing translation tasks into Payload's built-in Jobs Queue, drained by a Cloudflare Cron Trigger hitting /api/payload-jobs/run, with translations written back as drafts for human approval. (Don't use autoRun on serverless — the docs warn against it for good reason.)

What we shipped

Posts live in content/blog/posts/ as TypeScript modules with an English source translation and optional locale variants. Agents scout keywords, draft articles, and regenerate stale translations on a schedule; humans merge. The whole "CMS" is a types file and a registry — and it deploys with the rest of the site on Cloudflare Workers, no extra moving parts.