INFRA Signal 538
The Cloudflare Blog – Brought to you by EmDash
Cloudflare replaced its third-party CMS with EmDash, an in-house system built on Astro, to test its own stack under production traffic loads.
This migration demonstrates Cloudflare’s practice of using its own products internally to validate scale, security, and usability before customer adoption. The move also highlights the trade-offs of adopting pre-1.0 software in a high-traffic production environment. Engineers evaluating in-house tooling can learn from Cloudflare’s approach to stress-testing and iterative improvement.
Written by elseif from the cluster below · every claim links back to a sourceThe three things worth knowing
EmDash, an in-house CMS built on Astro, now powers the Cloudflare Blog after a full migration from a third-party vendor.
Cloudflare used performance tests like burst traffic simulations to validate EmDash’s ability to handle spikes up to 5,000 RPS.
Gaps in scheduled post functionality and admin usability were identified and addressed during the migration process.
THE READ
What the cluster adds up to.
Cloudflare’s migration of its blog to EmDash is a deliberate test of its own infrastructure. By adopting EmDash internally, Cloudflare enforces a cultural principle: its products must first prove themselves under the company’s own demanding production conditions. This approach ensures that issues are discovered and resolved before external customers encounter them. The migration also reflects a broader trend among infrastructure providers, using internal systems as a proving ground for scale and reliability. For engineers, this serves as a case study in how to validate in-house tooling before wider deployment.
The migration exposed practical challenges in adopting pre-1.0 software for a high-traffic production environment. Cloudflare’s blog receives variable traffic, with normal loads around 75 RPS and spikes exceeding 5,000 RPS. To validate EmDash’s readiness, the team ran performance tests using k6, simulating scenarios like gradual ramps, breakpoint tests, and sudden bursts of 7,000 RPS. These tests revealed gaps in scheduled post functionality and admin usability, which were addressed before full deployment. The process underscores the importance of stress-testing early-stage software under realistic conditions, especially when replacing a stable third-party system.
The trade-offs of this migration are instructive for engineers evaluating similar moves. Cloudflare prioritized control and alignment with its own stack over the stability of a mature third-party CMS. While EmDash met most usability requirements, the team identified limitations in media handling, localization, and SEO, areas where the previous vendor may have offered more polished solutions. The migration also required addressing Content Security Policy (CSP) nuances, which can complicate frontend integrations. For teams considering in-house tooling, this highlights the need to weigh the benefits of customization against the costs of maintaining and improving a less mature system.
Cloudflare’s approach to this migration aligns with its broader engineering philosophy, as outlined in its internal Codex. The company’s preference for in-house solutions is not absolute but is guided by a burden of proof: external vendors must be justified by gaps that cannot be filled internally. This mindset drives innovation but also demands rigorous validation. The EmDash migration demonstrates how Cloudflare applies this principle in practice, using its own blog as a real-world testbed. For engineers, this serves as a model for how to balance innovation with operational risk when adopting new tooling.
Written by elseif from the cluster below · checked for specifics the sources never containedTHE CLUSTER
↗