I decided to run kristian-lol as a Payload CMS + Next.js system on Cloudflare Workers, with signed publish and preview flows, so markdown content can move to production safely without adding a separate backend service.

What We Built

• A Cloudflare-first CMS stack: Payload + Next.js on Workers, with D1 for relational content state and R2 for media.
• A publish pipeline designed for automation: Git markdown/assets feed a CI publish script that calls /api/publish/sync, then writes through the Payload Local API.
• A controlled preview model: signed, short-TTL preview URLs (/api/preview/sign, /preview/:slug) for embed-friendly draft review.
• An operational workflow centered on scriptable commands for dev, type generation, content checks, integration/e2e tests, and environment-specific deploys.

Why We Built It

• I optimized for fast iteration with low operational overhead: the repo direction is explicitly “blog-first local knowledge base” with lightweight infrastructure.
• Security and correctness were treated as non-negotiable in project rules: TypeScript-first, strict access-control awareness, and required type/import-map regeneration after schema or component changes.
• Recent session history shows the real pressure points were reliability of memory/live-edit workflows (multiple retries around external-directory permissions and vault memory integration), so a durable, script-driven content path mattered more than adding platform complexity.
• The architecture in README.md reinforces the decision: content originates in markdown and lands in Payload-managed state, keeping editorial flow simple while preserving production controls.

How It Works

• Author content as markdown, then publish via the CI/scripted sync path into Payload-backed storage (D1 + R2), instead of writing directly in production systems.
• Use local/dev scripts (dev, generate:types, generate:importmap, check:content) to keep schema, runtime, and content validation aligned before deploy.
• Deploy in two phases (deploy:database then deploy:app) so migrations and worker release stay explicit and repeatable.
• Validate quality through integration and e2e test commands, matching the project’s “secure + type-safe” operating model for ongoing changes.