What happened
Cloudflare completed the migration of cdnjs — one of the web's most heavily trafficked open-source CDN libraries — onto its own Developer Platform, running the service entirely through Workers and Workflows at a sustained rate of roughly 9 billion requests per day. The move, described internally as dogfooding at scale, forced engineering teams to harden platform limits that now benefit all Cloudflare customers. Separately, AWS announced that Amazon EC2 Auto Scaling's Instance Refresh feature is now a native CloudFormation update policy. Teams can configure the new AutoScalingInstanceRefresh policy so that stack updates automatically trigger rolling instance replacements, including root volume swaps and other in-place update capabilities.
Why it matters for your business
For teams already building on Cloudflare Workers, the cdnjs migration is concrete evidence that the platform can sustain extreme production workloads — not just developer demos. Raised Workflows and Workers limits translate directly into higher ceilings for any business running compute-intensive or high-throughput edge applications. On the AWS side, the CloudFormation integration removes a workflow that previously required custom scripts or manual intervention: engineers can now declare instance refresh behavior in infrastructure-as-code and trust that fleet updates roll out consistently across environments. The practical takeaway is straightforward — both changes reduce operational toil and close gaps between what infrastructure promises on paper and what it delivers under real load.
What to watch next
Cloudflare's willingness to run a flagship public service on its own primitives signals continued investment in platform reliability; expect further limit increases and new primitive announcements as internal workloads stress-test the system. On the AWS side, broader CloudFormation parity with the full Instance Refresh API surface — including custom lifecycle hooks and checkpoint configurations — will determine how much operational complexity teams can retire from their deployment pipelines. Organizations evaluating either platform should treat these milestones as prompts to audit their current edge-compute ceilings and fleet update procedures.
