Most coverage of EmDash CMS since its April release has been speculative, because there was nothing substantial running on it in public. That changed quietly on August 12, 2026, when Cloudflare moved its own blog onto the CMS it built and then published the numbers. This piece covers what was migrated and how quickly, the stack underneath it, the performance figures Cloudflare released, the Model Context Protocol server that ships with the product, what bundled agent write access does to permission design, and what the migration does and does not demonstrate.
What Cloudflare actually migrated, and how fast
The cutover happened on Wednesday, August 12, 2026, and Cloudflare’s own write-up describes a rollout pattern more conservative than the single-day headline suggests.
Traffic moved in stages: 1% first, then 5%, then 15%, then upward through the day, reaching 100% by the end of it. A proxy Worker routed requests between the legacy system and the new one using version cookies, which is what made the incremental ramp possible and the rollback path real.
One day from 1% to 100% is fast for a property of this size. The staged shape of it is the part a team planning its own migration should copy.
The version-cookie approach is worth dwelling on, because it is the difference between a migration and a gamble. A cookie pinning each visitor to one system or the other means a user who lands on the new stack stays there for the session rather than bouncing between two rendering paths, and it means the percentage dial can move in either direction at any point. Plenty of CMS migrations are still run as a DNS change on a weekend with a database backup as the only rollback plan. This is what the alternative looks like on a property that cannot afford an outage.
The stack underneath
The architecture is entirely Cloudflare’s own platform, which is both the point and the caveat.
| Layer | Component |
|---|---|
| Application | EmDash running on a Cloudflare Worker |
| Front cache | Workers Cache |
| Object cache | EmDash object cache built on Workers KV |
| Database access | Hyperdrive to PlanetScale |
| Routing during cutover | Proxy Worker using version cookies |
Nothing here is exotic. It is a Worker in front of a Postgres-compatible database with two cache layers, which is a shape any team on the platform could reproduce. The dependency on Workers KV and Hyperdrive does mean the reference architecture is not portable off Cloudflare without substitution, and that is a real consideration if you are evaluating EmDash as a WordPress alternative rather than as a Cloudflare product.
The numbers they published
Cloudflare released enough detail that the claims can be checked rather than taken on faith.
Normal load on the blog runs around 75 requests per second, with peaks above 5,000. The migrated stack served up to 850 requests per second in testing. Caching does most of the work: 99.5% of static files and 70% of all requests are served from a cache.
Load testing used k6, Grafana’s open-source tool, with failure thresholds set at 500ms for P95 and 1,000ms for P99.
The real-world stress test was better than the synthetic one. Agents Week put 28 new posts out over 9 days for roughly 3 million pageviews, during which the frontend handled up to 450 requests per second without trouble. On August 10 the site absorbed a 28,000 request-per-second DDoS attack.
That last figure deserves a caveat rather than applause. Cloudflare absorbing a DDoS on Cloudflare infrastructure is the company demonstrating its own core product, not evidence about the CMS.
The cache numbers are the ones that actually characterize the system. Serving 70% of all requests from cache means the origin Worker handles under a third of traffic, and at 75 requests per second normal load that is a very small amount of real work. A publishing site is close to the friendliest possible workload for this architecture, which is worth remembering before extrapolating the figures to anything transactional.
EmDash CMS ships an MCP server as standard
Here is the part that matters more than the performance numbers, and that almost nobody has covered.
EmDash includes an MCP server for EmDash itself, letting authors browse, create, edit, publish and schedule posts through an agent. Cloudflare separately released a Model Context Protocol server for the blog as a reader-facing surface, exposing search_posts, list_posts, get_post and list_tags.
Both are available without additional cost.
Read that as a product decision rather than a feature list. Every other CMS in this category treats agent access as something you install: a plugin, an integration, a separately configured server with its own credentials and its own permission surface. EmDash treats it as part of the CMS.
Agent write access as a default changes the permission question
We looked at what happens when agents get write access to a content system in our piece on CMS MCP agent permissions. The assumption running through that piece, and through most current practice, is that agent write access is a decision somebody makes.
If the MCP server is bundled and enabled as standard, that decision has been made for you at install time. The question stops being whether to grant agent access and becomes what the default scope is and how you narrow it.
Those are different problems. The first is a governance question you can defer. The second is a configuration question that exists from day one, and it needs an answer before the first author connects an agent rather than after.
Three questions worth settling before an agent touches a live content system, whatever CMS you run:
| Question | Why it matters on day one |
|---|---|
| Can the agent publish, or only draft? | Publish and schedule are irreversible in public; draft is not |
| Whose credentials does it act under? | Shared service accounts destroy the audit trail |
| Is deletion in scope? | Almost never needs to be, and is rarely excluded by default |
None of that is exotic access control. It is the same reasoning applied to human editorial roles, which most publishing teams settled years ago and are now quietly re-opening for a non-human actor.
This is the direction we expected in our look at headless CMS MCP standardization, arriving sooner than that piece assumed and from a vendor with the platform reach to make it a norm. Teams evaluating a headless CMS should now be asking what the shipped MCP server can do by default, the same way they would ask about REST API authentication. Compare that with a traditional API-first platform such as Contentful, where the agent layer is something you assemble.
Astro 6 underneath, MIT on top
EmDash CMS is MIT-licensed and built on TypeScript and Astro 6, which puts it on the same foundation we covered in our Astro 6 piece. The source is public.
That matters for two practical reasons. Teams already running Astro have transferable knowledge rather than a new framework to learn. And an MIT license on a CMS from a large infrastructure vendor means the exit path exists in principle, though the reference architecture’s dependence on Workers KV and Hyperdrive means the practical exit is more work than the license implies.
Cloudflare has been describing EmDash as a spiritual successor to WordPress since April. That is marketing rather than a technical claim, and the gap between a Worker-hosted publishing system and an ecosystem of tens of thousands of plugins is not closed by a license choice.
What this does and does not prove
What the EmDash CMS migration does prove is deployability under real conditions. A high-traffic production property migrated in a day with a staged rollback path, then survived a heavy publishing week and a substantial attack. That is meaningfully more than any other EmDash deployment has shown publicly.
What it does not prove is generalizability. Cloudflare ran Cloudflare’s CMS on Cloudflare’s platform with Cloudflare’s engineers, and every number came from Cloudflare. None of that is dishonest, and the figures are specific enough to be checkable, but a vendor migrating its own property is the most favorable possible case.
It also proves nothing about the migration path from anywhere else. Cloudflare moved from its own previous system with full knowledge of both ends. A team coming off WordPress with fifteen years of posts, custom fields, redirects and plugin-generated markup faces a content modeling problem that this migration did not have to solve, and Cloudflare has published nothing about that path.
The signal to take from this is not that EmDash CMS is ready to replace your CMS. It is that agent access to a content system is becoming a default rather than an add-on, and that shift will reach whatever platform you are on.
Frequently Asked Questions
What is EmDash?
An MIT-licensed content management system built by Cloudflare on TypeScript and Astro 6, released in April 2026 and designed to run on Cloudflare Workers. Cloudflare has described it as a spiritual successor to WordPress.
When did Cloudflare move its blog onto it?
The cutover ran on Wednesday, August 12, 2026, ramping from 1% of traffic through 5% and 15% to full deployment by the end of the same day, with a proxy Worker using version cookies to route between old and new.
What performance did they report?
Around 75 requests per second at normal load with peaks above 5,000, up to 850 requests per second served in testing, and 99.5% of static files plus 70% of all requests coming from cache. Load testing used k6 with 500ms P95 and 1,000ms P99 failure thresholds.
What happened during Agents Week?
28 posts over 9 days and roughly 3 million pageviews, with the frontend handling up to 450 requests per second. The site also absorbed a 28,000 request-per-second DDoS on August 10, though that says more about Cloudflare’s network than about the CMS.
What does the MCP server actually do?
There are two. The EmDash MCP server lets authors browse, create, edit, publish and schedule posts through an agent. A separate server for the blog exposes reader-facing tools: `search_posts`, `list_posts`, `get_post` and `list_tags`. Both come at no additional cost.
Can EmDash run outside Cloudflare?
The license permits it, but the published reference architecture depends on Workers, Workers KV and Hyperdrive. Running it elsewhere means substituting those layers, so treat portability as possible rather than straightforward.
Is this a genuine WordPress replacement?
Not yet, and the comparison is Cloudflare’s framing rather than a technical claim. The publishing core is proven under load, but WordPress’s advantage is an enormous plugin and theme ecosystem that a license choice does not address.
What should we take from this if we are not moving CMS?
The bundled MCP server. Agent write access to content is shifting from something you install to something that ships enabled, which turns permission scoping into a day-one configuration question rather than a later governance decision.
