Cloudflare has outlined how it moved its main blog from WordPress to EmDash, the open source content management system it built internally, and the company says the switch delivered a faster, more reliable reading experience. The migration is notable not just because Cloudflare is replacing a long-established CMS with its own TypeScript-based platform, but because it was done with a staged rollout, multiple caching layers, and a fallback path designed to avoid downtime.
Cloudflare’s WordPress replacement is now its own “Customer Zero” test
Cloudflare first introduced EmDash in a developer preview as version 0.1.0 last April, describing it as a successor to WordPress. In its latest write-up, the company said it decided to use its own blog as the first real production deployment of the platform after identifying limits in the older setup.
The blog itself is a high-visibility workload. Cloudflare said it typically serves about 75 requests per second, but spikes above 5,000 requests per second are common, making performance and caching central requirements rather than nice-to-have optimizations. The company said that the new platform was tested to handle traffic of up to 7,000 requests per second.
As the company explained, becoming “Customer Zero” meant Cloudflare could prove the platform against its own traffic and internal editorial needs before broader use. That also gave the team a live environment to validate how EmDash behaved under realistic load.
What EmDash is and how Cloudflare runs it
EmDash is Cloudflare’s internally developed CMS, built in TypeScript and designed to take over from WordPress. The production deployment for the Cloudflare Blog is not a simple rewrite on a single server; it runs on a Worker with several layers of caching and a database connection path tuned for Cloudflare’s infrastructure.
According to the company, the setup includes Workers Cache and an EmDash object cache built on Workers KV. Cloudflare also uses Hyperdrive to connect EmDash to a PlanetScale database. That architecture is intended to reduce latency and improve cache efficiency, which matters when a site sees both steady traffic and sudden spikes.
The company said the new stack improved the site’s consistency, pointing to p95 response latency comparisons between the older architecture and the EmDash deployment. In Cloudflare’s description, the previous platform had periodic latency spikes under load, while the new system produced a flatter response profile.
That difference matters for readers as much as for infrastructure teams. A site can appear healthy at average levels while still feeling slow during bursts, and the company’s goal was to reduce that volatility across the board.
A gradual cutover from WordPress to EmDash
Cloudflare did not move all traffic at once. Instead, it used a proxy Worker to route requests gradually from WordPress to EmDash, beginning with 1% of traffic and increasing the share as the team verified the new platform. The rollout eventually reached 100% in a single day.
The proxy Worker also handled traffic segmentation through a version cookie, allowing incoming requests to be routed to the legacy or new experience depending on the assigned cohort. Just as important, the worker could fall back to the legacy blog if the new site encountered 500 errors.
That staged approach is the sort of migration pattern many engineering teams aim for but do not always implement cleanly. Cloudflare’s version included a kill-switch-style fallback, cohort-based routing, and progressive exposure, which helped the team contain risk while still moving quickly.
Why the rollout strategy mattered
- Reduced risk: Traffic could be shifted gradually instead of forcing a full cutover.
- Fast rollback: Errors on the new site could send users back to the legacy WordPress blog.
- Better validation: The team could observe behavior at each traffic level before proceeding.
- Cache testing: Progressive traffic made it easier to spot regressions in the new caching layers.
In Cloudflare’s own explanation, the proxy Worker “intelligently route[d] traffic” between the legacy blog and the new EmDash-powered site, using the version cookie to maintain a consistent experience for each request. That approach let the company validate performance while still protecting readers from a bad rollout.
Performance gains and the editing experience
Cloudflare says the migration resulted in a faster and more reliable site, with a markedly steadier latency profile under load. The company’s blog post presents the new setup as a clear improvement over the older WordPress-based architecture, especially during periods when traffic surges.
The benefits were not limited to page delivery. Cloudflare also said the move improved access for AI agents by introducing a new MCP server for the Cloudflare Blog and another for EmDash. Those servers allow authors to browse, create, edit, publish, and schedule content through the platform.
At the same time, the company acknowledged early adoption issues. Editors encountered some problems, mainly around the editing experience and scheduled posts. Cloudflare said those issues were reported back to the EmDash team, which is working toward a v1 release, although no official date has been announced.
That combination of positives and caveats gives the migration a practical feel. The new system appears to have solved the performance and reliability concerns that helped motivate the move, but the editorial toolchain still needs refinement before EmDash can be considered fully mature.
What the migration suggests for WordPress and CMS teams
Cloudflare’s move is less about a single company swapping one platform for another and more about how modern CMS deployments are evolving. The company is betting that a custom, worker-based system can deliver stronger performance, more flexible caching, and tighter integration with its broader platform than a traditional WordPress setup.
For teams watching the migration, the interesting parts are the engineering choices around rollout and resilience. The combination of proxy-based traffic shifting, cookie-based cohorting, caching layers, and automatic fallback is a clear example of how to de-risk a major platform change in production.
The announcement also shows how CMS projects are increasingly being evaluated on more than publishing features alone. Editorial workflow, AI integration, cache behavior, and infrastructure portability all played a role in Cloudflare’s decision and its assessment of the results.
Cloudflare has not announced a public release date for EmDash v1, but the company’s own blog migration suggests it is willing to use the platform in production before that milestone arrives. For now, the Cloudflare Blog serves as both a live site and a proving ground for the CMS intended to replace WordPress in at least one important corner of the company.
Source: Original report
Was this helpful?
Explore more: WordPress Troubleshooting More WordPress & CMS Tech News
Last Modified: September 26, 2026 at 10:33 pm
1 views
