On August 12, Cloudflare completed the migration of its blog to EmDash, a content management system built to work with Astro and Cloudflare, as part of a project that went beyond redesigning the interface. The company used its blog as the “zero customer” to test the new platform on real production traffic, focusing on scalability, response speed, and the safety of the transition from the legacy system.
Cloudflare says the migration revealed needs related to the blog’s size and complexity and allowed the team to improve EmDash before rolling it out more broadly. Because the results and measurements come from the company itself, they represent a one-sided published operational experience rather than an independent test of the platform.
Testing the Platform Before Testing Performance
The team began with a practical question: Does EmDash actually work with Cloudflare’s needs? To answer it, they tested core workflows such as creating, publishing, unpublishing, and scheduling posts, adding media, searching content entities, and managing author names.
The largest gaps appeared in handling the large volume of media and content, as well as in translation details, search engine optimization, and content security policies (CSP). The administration editor also needed improvements for finding custom HTML blocks, handling errors within the content editor, and keeping the formatting bar visible while editing long posts.
Scheduled posts were the most significant issue discovered; they did not work until EmDash version 0.19.0. This illustrates the value of testing complete operational workflows before relying on a new system, because the defect would not necessarily have appeared in a test of creating or immediately publishing content.
Load Tests Simulating Volatile Traffic
Traffic on Cloudflare Blog typically hovered around 75 requests per second, but could exceed 5,000 requests per second, either when a new post went viral or because of spikes unrelated to a specific publishing time. The team therefore designed tests using the open-source k6 tool, including a gradual increase in load to three times the baseline, a test that started at zero and reached 100 requests per second over ten minutes, and an immediate burst test at 7,000 requests per second for one minute.
Failure criteria were based on three indicators: HTTP 5xx errors could not exceed 0.01%; the response time for 95% of requests could not exceed 500 milliseconds; and the response time for 99% of requests could not exceed one second. These limits turned the question “Is the platform fast?” into measurable operational conditions.
A Multilayer Architecture and a Clear Fallback Path
Cloudflare chose to run EmDash on a Cloudflare Worker behind Workers Cache, using EmDash’s new object storage built on Workers KV, along with Hyperdrive’s integration with PlanetScale. The caching layers served 99.5% of static files from cache and approximately 70% of all requests from cache, according to the company’s data, reducing pressure on the database.
To prevent service downtime during the transition, the team created a Proxy Worker that distributed requests between the old blog and the new site. It identified the trial version through a cookie, with the ability to route requests back to the legacy system when 500 errors appeared on the new site. The team also used a direct connection between Workers through the NEW_BLOG service binding to avoid routing through a public domain name, DNS and TLS operations, and an external HTTP connection.
The gradual rollout began with 1% of traffic, then increased to 5% and 15% before reaching 100% at the end of the day. This made it possible to monitor real-world load and identify edge cases without exposing most readers to an unstable change.
What Changed in Practice?
Cloudflare says the new architecture maintained more stable response times compared with the previous platform, with performance gains and limited errors while serving up to 850 requests per second. During Agents Week, 18 blog posts were published over nine days and generated nearly 3 million views, while the new Worker served up to 450 requests per second without noticeable issues. The integrated DDoS protection also absorbed an attack reaching 28,000 requests per second on August 10, according to the company.
The change also included the interface, which was rebuilt according to Kumo design system patterns, with native support for light and dark modes based on system preferences and a manual toggle. The email subscription prompt was moved to the end of the article, and a “On this page” table of contents and a “Discuss online” option were added to improve navigation and engagement.
The new EmDash interfaces and AI search endpoints made it possible to create an MCP server for the Cloudflare Blog in a few hours, with tools for searching, listing, and retrieving posts and listing tags. EmDash’s own MCP server also allows writers to browse, create, edit, publish, schedule, and remove content at no additional cost, according to the source.
The editing experience itself remains incomplete; Cloudflare continued to record minor issues and bugs related to scheduled posts, said it had escalated them to the EmDash team, and expected them to be fixed before Birthday Week. The case therefore does not demonstrate that the platform is free of limitations, but it does illustrate a practical approach: testing content workflows before performance, defining explicit failure thresholds, building a fallback path, and then expanding the rollout gradually instead of executing a full migration all at once.