A Production-Ready CMS as a Cloudflare Reference

The Cloudflare documentation is thorough when it comes to individual APIs and concepts, but there is a significant divide between its introductory snippets and a fully functioning, production-ready application. That gap is not unique to Workers—any developer moving to a serverless model has to rethink how applications are assembled. To help bridge that distance, Cloudflare is doing something unusual: building a complete, example SaaS application entirely on its own stack, in the open.

The project, hosted on GitHub, is free to use and developed publicly. It serves double duty as both a learning resource and a template—developers can clone the repository, swap in a few service tokens, and deploy the pre-built application to their own Cloudflare account in minutes. The codebase is also intended as a living example, updated continuously to reflect changes in the Workers platform and evolving best practices.

To be useful as both a case study and a template, the example had to be complex enough to demonstrate real architectural decisions, yet self-contained enough to follow without a steep onboarding curve. A content management system (CMS) fits that brief well.

Why a CMS?

The CMS archetype has changed considerably over the years. Traditional systems like WordPress ran on long-lived servers, querying an SQL-like database on every request, rendering HTML, and repeating. Later iterations added caching layers or skipped the database altogether by pre-rendering content as static HTML at build time—the approach now known as static-site generation.

Serverless and edge computing have pushed the model further toward "headless" CMSes. Instead of being monolithic web servers, these are API-first content backends that return raw JSON. Developers then build their own presentation layer with whatever tools they prefer, while still getting content organization and asset management. Providers like Sanity.io and Contentful are well-known in this space, and WordPress itself supports both headless and traditional modes.

For an edge-first design, a CMS is a natural fit. Content should sit as close to the requesting user as possible, and a serverless architecture eliminates the single point of failure. Those two benefits map directly onto the CMS use case, making it a compelling demonstration of Cloudflare's platform.

What Exists Today

The project is not vaporware—substantial work is already public in the GitHub repository. The current implementation pairs Workers with Workers KV and Rate Limiting, and also uses Cloudflare for SaaS. Pages and Durable Objects are planned for later milestones.

Phase 1 of the roadmap is close to completion. When it wraps up, it will represent a meaningful milestone: a working, full-stack application that stands on its own as a usable product. An update to this series will provide a technical overview of what that phase accomplished.

Building the CMS Through Phased Milestones

The project is already live on GitHub, where you can track progress against the roadmap and subscribe to updates for specific milestones. Each phase represents a substantial checkpoint that adds significant new functionality or integrates a new Cloudflare product. The application remains functional throughout, with a live demo available at every stage so visitors can immediately interact with the latest additions.

Visit the GitHub milestones page for full details and update subscriptions — far more is planned than what appears below.

Phase 1: Core JSON API

The first milestone lays the foundation with API endpoints built on Workers and Workers KV. There is no HTML, CSS, or client-side JavaScript here — this phase deals purely with data: how it is accessed, how models relate to one another, and how those relationships are stored in Workers KV. Users can create and manage workspaces tied to personal accounts or to organizations they belong to.

Content creation includes schema validation, a critical feature for any CMS expected to handle thousands of documents per workspace. Without enforced schemas, there is no confidence that the JSON representation of content stays consistently structured.

Additional planned features include Stripe-powered subscription management and invoicing, SendGrid for transactional email, and vanity domain assignment through Cloudflare for SaaS. Standard house-keeping tasks — CI with API testing and automated CD — are set up as well.

After Phase 1, the project is already a complete application exposed as a collection of API endpoints, accessible via curl or any other HTTP client. The repository demonstrates best practices for tests, automated deployments and source organization that scale with long-term growth. Since it starts as a JSON API, the project is immediately usable as a personalized Headless CMS, and the source can be deployed to your own Cloudflare account right away.

Phase 2: Dashboard UI

The second milestone adds a visual interface using Svelte, chosen because its templating closely resembles standard HTML — non-frontend developers can follow along. The design system uses Tailwind CSS, a utility-first framework with reusable class names for composing styles.

The result is a single-page application hosted on Cloudflare Pages, taking advantage of Access-protected preview deployments, instant rollbacks, automated deployments and analytics. Because Pages now integrates directly with Workers, the Phase 1 JSON API migrates into the same repository structure. This unlocks the same Pages features for the API — preview deployments, rollbacks and automated deploys — all applied atomically across the entire application. There is zero risk of the API and the dashboard drifting out of sync, since both ship as a single Pages unit.

Completing this phase makes the application usable as a daily product and a credible contender for a Headless CMS service.

Phase 3: Edge Rendering of Articles

This phase expands beyond the headless archetype by rendering HTML pages from JSON content injected into predefined templates. Users choose freely between the headless API and the full template engine, much like WordPress. The project ships only a small set of premade templates to select from, though you can customize them in your own deployments.

Although this reintroduces the monolithic CMS form, the design is safer, faster and more resilient than an all-in-one server. Content is distributed close to readers worldwide, and HTML rendering can now happen from anywhere at very low latency.

Phase 4: Feature Expansion

With the core product functional and usable in two distinct modes, development shifts toward user-facing features and maintenance work. Phase 4 plans introduce Durable Objects to power a collaborative, real-time document editor where multiple users can edit the same document. Cloudflare R2 Storage is a likely backend for media uploads and management — or Cloudflare Images for asset handling, with R2 supporting content import/export backups.

The specifics of this phase remain open-ended by design, and the project evolves continuously with Cloudflare as new capabilities become available. If you have feature ideas, open a discussion on GitHub.

What's Next

This is the first post in an ongoing series. Each completed milestone will receive a retrospective post with technical walkthroughs of key aspects from that phase.

Star or follow the project on GitHub to track releases, discussions and milestones. All roadmap details and updates live in the repository.