Why Cloudflare Rebuilt Its Own Blog on an AI-Native CMS — and What That Says About the Next Content Stack

Cloudflare didn’t just launch a product and hope someone would use it. It moved one of the highest-traffic technical blogs on the internet onto EmDash first, absorbing the risk itself before asking any customer to do the same. That decision — and what it reveals about how content infrastructure is evolving — is worth unpacking carefully, because the underlying shift extends well beyond one company’s blog.

The "Customer Zero" test

Cloudflare has a stated internal principle it calls being "Customer Zero": before a product ships to paying customers, Cloudflare tries to run its own infrastructure on it first. The logic is straightforward — if something breaks, it breaks Cloudflare’s own systems before it breaks anyone else’s, which creates strong internal pressure to fix problems fast.

For EmDash, that meant answering two blunt questions before committing: does the platform actually work for day-to-day publishing, and can it survive Cloudflare-scale traffic? The publishing question surfaced the kind of friction you’d expect from software still in beta — the company has described EmDash as being in beta preview around version 0.1.0 in the months before this migration — including a period where scheduled posts simply didn’t work until a later release, and rough edges in the editing interface for long-form technical posts. None of that is surprising for a pre-1.0 product, but it’s worth naming plainly: this was not a mature, battle-tested platform being dropped onto a flagship property. It was closer to a live pilot with a very demanding, very public test subject.

The scaling question was answered more rigorously. Cloudflare’s blog traffic is unusually spiky — a steady baseline around 75 requests per second that can rocket past 5,000 during a viral post. The team used an open-source load-testing tool to simulate gradual ramps, breakpoint tests, and sudden bursts up to 7,000 requests per second, checking both error rates and response latency under each scenario. The production setup that emerged from those tests — EmDash running on Cloudflare Workers, sitting behind a new caching layer, backed by a database integration built for the occasion — reportedly serves the vast majority of requests from cache, with Cloudflare noting it was serving over 99% of static files and roughly 70% of overall requests from cache after the move. During Cloudflare’s own "Agents Week" event in August, the new blog handled 28 posts and close to three million pageviews without major incident, including absorbing a large denial-of-service attempt without visible disruption to readers.

That’s a meaningful data point, but it should be read for what it is: one company validating its own product on its own infrastructure, with its own engineers on call. It demonstrates that a serverless, edge-deployed CMS can handle serious production traffic — something that was largely theoretical a year earlier. It does not yet demonstrate how EmDash performs for organizations without Cloudflare’s engineering depth, or at traffic patterns very different from a tech blog’s.

From rendered pages to structured data

To understand why any of this matters beyond Cloudflare’s own operations, it helps to step back and look at what a content management system actually does, and how that job has changed.

The first generation of CMS platforms — WordPress is the enduring example, first released in 2003 — grew out of desktop publishing tools and were designed around a simple mental model: an editor writes a post, the server assembles that post into a complete HTML page, and a browser displays it. Content and presentation were tangled together by design; the database stored rich text as HTML, often with formatting metadata embedded directly in the markup. This worked well for two decades because the target audience for a webpage was, reliably, a human with a browser.

The next shift, sometimes called "headless" CMS, decoupled content from presentation. Instead of a server assembling finished pages, the CMS exposed content through an API, and separate front-end applications — a website, a mobile app, a smart display — could each request and render that content however they liked. This mattered as businesses needed the same content to appear across many channels, and as JavaScript frameworks took over front-end development from server-rendered templates.

EmDash represents a further step in that lineage, and it’s the one this story is really about. Rather than storing rich text as HTML, EmDash stores content as structured JSON in a format called Portable Text — essentially, a typed, machine-parseable data structure rather than a document. Concretely: instead of a database field holding a paragraph tag with a bolded phrase and a caption buried in an HTML comment, EmDash stores a strongly typed object where "heading," "body," "author," and "publish date" are each explicit, addressable fields with defined types. A human editor still sees a familiar rich-text editor on screen — EmDash uses a standard editing toolkit for that — but what gets saved underneath is not a page fragment, it’s data.

That distinction sounds like a technical nuance, but it has a real consequence: an AI system trying to summarize, search, or answer questions about that content no longer needs to parse HTML tags, strip out navigation clutter, or guess at what’s a heading versus a caption. The structure is already explicit. This is why Cloudflare frames EmDash’s content layer as "grounding-enabling" — a system whose native output is already in a form a language model can reliably interpret, rather than something that needs to be scraped and reverse-engineered.

The table below lays out how these three generations compare across the dimensions that actually matter to someone choosing a platform today.

Each transition in that table happened for a reason. Server-rendered CMS platforms gave way to headless architectures once businesses needed one body of content to power many different screens. Headless platforms are now being pushed toward edge-native designs for two compounding reasons: serverless infrastructure lets code run close to the reader rather than in one distant data center, cutting latency and letting operators pay only for the compute they actually use instead of renting a server around the clock; and, more recently, AI agents have become a second class of "reader" that a content system needs to serve directly, not as an afterthought bolted on through a scraper.

One request, two very different readers

That second point is easiest to see visually. When EmDash serves a page, the underlying content object doesn’t change depending on who’s asking — but the path a request takes, and what comes back, differs depending on whether the requester is a person’s browser or an AI agent calling the built-in Model Context Protocol server.

flowchart LR
 Editor[Editor writes post] --> Store[Structured JSON store]
 Store --> Cache[Edge cache layer]
 Cache --> Browser[Human browser]
 Cache --> MCP[MCP server]
 MCP --> Agent[AI agent]

The same underlying content object is the source for both paths. For a human reader, the edge cache layer returns a fully rendered page — Cloudflare says it now serves the large majority of blog requests straight from cache, which is a big part of why response times stayed flat even under the load spikes of Agents Week. For an AI agent, that same content is exposed through tools like "search posts," "list posts," and "get a specific post" via the MCP server, without requiring the agent to fetch and parse a rendered web page at all. Cloudflare has said that, once the underlying content and search APIs existed, building this MCP integration for its own blog took a matter of hours rather than a dedicated project — a small but telling sign of what changes when agent access is designed into the platform from the start rather than added on top of it afterward.

The Model Context Protocol itself is worth pausing on, because it’s easy to hear "AI agent interface" and picture something exotic. It isn’t. MCP is an open standard, developed by Anthropic, that lets an AI system discover and call external tools through a predictable, documented interface — conceptually similar to how a human developer uses an API, or how a phone app uses a plugin. What’s new with EmDash isn’t the existence of MCP; it’s that an MCP server ships as a standard part of every installation, at no extra cost, rather than being a premium add-on or a third-party integration a customer has to build separately.

The plugin security trade-off

The other structural change worth understanding closely is how EmDash handles plugins, because it reframes a problem that has quietly plagued the CMS industry for years.

WordPress’s plugin model is, essentially, a script with full run of the house: a plugin can read and write the database, touch the filesystem, and act with the same trust level as the core software itself. That openness is a large part of why WordPress built such an enormous plugin ecosystem — developers could do almost anything — but it also means a single careless or malicious plugin can compromise an entire site. Independent reporting on WordPress security has repeatedly pointed to plugins as the dominant source of vulnerabilities, with figures cited putting the share of security issues originating in plugins in the high nineties percent range.

EmDash’s answer is to run each plugin inside its own sandboxed, isolated worker environment, with permissions declared upfront in a manifest — a model closer to the "scopes" screen you see when an app asks to access your calendar or photos than to a script with unrestricted system access. A plugin that asks only to read content and send email gets exactly those two capabilities and nothing else; it cannot reach the database or the filesystem directly, because the sandbox simply doesn’t expose them. That’s a meaningfully different security posture, and it directly answers a well-documented, longstanding weakness in the older model.

It’s worth being precise, though, about what this trade-off protects against and what it assumes. Sandboxing limits the damage a compromised or badly written plugin can do — it shrinks the attack surface from "everything" to "whatever was explicitly declared." What it doesn’t automatically guarantee is that the isolation technology itself, or the manifest system, or the newly-introduced MCP interface, is free of its own undiscovered flaws; sandboxes have historically had escape vulnerabilities in other contexts, and a standard as young as MCP invites scrutiny precisely because it hasn’t yet been tested at wide scale across many independent implementations. There’s also a practical dependency worth flagging: EmDash’s sandboxed plugin execution relies on a Cloudflare feature that currently requires a paid account, meaning the security benefit of isolation is tied to a specific paid infrastructure tier rather than available uniformly for free across every deployment option. None of that erases the structural improvement — it just means "sandboxed" is a real design choice with real trade-offs, not a blanket guarantee that the system is safer than every alternative in every configuration.

Not a WordPress killer — a different tool for a different job

It’s tempting, given how EmDash is often described — as a "spiritual successor to WordPress" — to frame this as a straightforward replacement story: old CMS bad, new CMS good, migrate now. That framing doesn’t hold up well, and it’s worth being explicit about why.

WordPress runs a very large share of the web precisely because it’s forgiving, familiar, and enormously well-supported: cheap shared hosting, a massive plugin marketplace, an army of freelancers and agencies who know it, and two decades of documentation for every conceivable use case. For a small business site, a local newsroom, or a hobby blog, that ecosystem maturity is worth more than an elegant content model or a built-in AI interface most of those sites will never fully use.

EmDash is aimed at a different problem: high-traffic, technically sophisticated properties that need to survive unpredictable spikes, want content that’s natively legible to AI systems, and are comfortable operating (or paying someone to operate) serverless infrastructure rather than a conventional web host. Cloudflare’s own blog — with its multi-thousand-request-per-second surges and appetite for agent-facing tooling — is close to a best-case scenario for this architecture, not necessarily a representative one. It also runs on Cloudflare’s own network, tuned by the engineers who built both the CMS and the underlying edge platform; that’s a very different starting position than a mid-sized publisher evaluating whether to move off a hosting plan they already understand.

There’s also a genuine, unresolved debate inside the CMS world about the core design choice underneath EmDash: is storing everything as structured, typed JSON actually better for editors, or does it trade away some of the flexibility that made freeform HTML editing so easy to reason about? Proponents argue structured content is more reusable and dramatically friendlier to both automation and AI tooling. Skeptics point out that rigid schemas can make certain kinds of ad hoc, creative formatting more cumbersome than just dropping in a block of HTML. Both positions have merit, and which one wins for a given team will depend on what they’re publishing and who’s doing the editing.

None of this should be read as a claim that edge-deployed serverless platforms are simply cheaper or better across the board — costs on serverless infrastructure are usage-based, charged by execution time and requests rather than a flat monthly server fee, which tends to favor sites with spiky, unpredictable traffic and can be less advantageous for steady, low-traffic sites that would do fine on a modest fixed-cost host. The honest way to think about EmDash isn’t "new versus old, better versus worse." It’s a tool shaped for a specific class of workload — and Cloudflare’s own blog happens to sit near the center of that class.

What’s still unsettled

A few things about this shift remain genuinely open rather than settled, and it’s worth naming them rather than glossing over them. Cloudflare’s own numbers describe how EmDash performed on Cloudflare’s infrastructure, under Cloudflare’s engineering supervision — independent, third-party benchmarks of EmDash under sustained production load on other organizations’ sites don’t yet exist in public form. The plugin sandbox model is a sound structural improvement over unrestricted plugin access, but a full independent security audit of that sandbox and of the MCP server implementation hasn’t been published either, and as MCP servers spread across more products industry-wide, they become a more attractive target simply by virtue of being more numerous. And the broader vision of AI agents as first-class users of content platforms — reading, searching, even publishing through tools like EmDash’s MCP server — is still early enough that how agent identity, permissions, and payment for agent-driven actions will actually be regulated and standardized is very much unresolved, not a settled outcome.

What is reasonably clear is the direction of travel. Content is increasingly being treated as structured data that can be reused across many surfaces rather than as a finished page meant for one browser window. Compute is moving closer to the reader, running in short bursts at the network edge rather than sitting reserved on a server around the clock. And software is starting to be built with the assumption that some of its "users" will be autonomous programs calling an interface rather than people clicking a mouse. Cloudflare rebuilding its own blog on EmDash doesn’t prove that every organization should follow — but it does show, concretely, that this combination of ideas now works well enough to carry real production traffic, which a year ago was still mostly a claim on a roadmap.

Sources

1. The Cloudflare Blog – Brought to you by EmDash
2. EmDash | Definition, Architecture and Access (Grounding Page)