Cloudflare Fully Adopts Astro—So We Are Too

On January 16, 2026, Cloudflare announced that The Astro Technology Company—the team behind the Astro web framework—is joining Cloudflare. Astro powers content-driven sites for brands like Porsche, IKEA, OpenAI, and for platforms like Webflow Cloud and Wix Vibe; Cloudflare already uses Astro for its developer docs, website, and blog. [Cloudflare blog, Jan 16, 2026]

This piece walks through what Cloudflare and Astro actually said about the acquisition, how it came together, and why it matters if you run both stacks in tandem—as we do at FEDLIN for content-driven sites and edge security.

Cloudflare's press release stated that the Astro team would join Cloudflare and that Astro would remain open source "to ensure the long-term growth and development of the project under Cloudflare's stewardship." The companies framed the move as "doubling down on a sustainable future for Astro to remain the definitive framework for content-driven websites." [Cloudflare press release, Jan 16, 2026]

The same day, Cloudflare published a joint blog post with the Astro team (Brendan Irvine-Broque and Fred Schott) that spelled out what the move means for Astro: it will remain open source, MIT-licensed, and open to contributions, with a public roadmap and open governance. All full-time employees of The Astro Technology Company are now Cloudflare employees and will continue to work on Astro. The post also noted that Cloudflare is committed to continuing support for open-source contributions via the Astro Ecosystem Fund, alongside partners including Webflow, Netlify, Wix, Sentry, and others. [Cloudflare blog, Jan 16, 2026]

Astro's own post on the acquisition—"The Astro Technology Company joins Cloudflare"—filled in the backstory. The Astro Technology Company had raised funding in 2021 to support the framework and explore a business around it; they tried hosted primitives and other ideas, but nothing gained traction the way Astro did. The distraction of building a business on top of the framework took a toll. [Astro, joining Cloudflare]

Last year, Fred Schott and Dane (Cloudflare's CTO) began talking seriously about the future of the web. Those conversations grew: What does the next decade look like? How do frameworks adapt to a world of AI coding and agents? They realized they had been working toward the same vision from different angles—Astro from the framework side (fast by default, content-driven), Cloudflare from the infrastructure side (global by default, fast startup, low latency, security built-in). [Astro, joining Cloudflare]

Cloudflare had been a long-time sponsor of Astro (including a $150,000 donation). Astro stated that staying open to all platforms was a non-negotiable requirement for both sides—so Astro remains free, open-source, MIT-licensed, and platform-agnostic, with support for all deployment targets, not just Cloudflare. [Astro, joining Cloudflare]

Both the Cloudflare and Astro announcements spelled out the same commitments:

• • Astro stays open source and MIT-licensed, with open governance and a public roadmap.
• • Astro remains platform-agnostic—deploy to any platform or cloud; first-class Cloudflare support does not mean Cloudflare-only.
• • The Astro team continues to work on Astro full-time as Cloudflare employees; open-source contributions continue to be supported via the Ecosystem Fund.

Technically, the acquisition coincided with Astro 6. The Cloudflare blog stated that Astro 6 brings a redesigned dev server that runs your code locally using the same runtime you deploy to. When you run astro dev with the Cloudflare Vite plugin (or deploy with the Cloudflare adapter), your app runs in workerd—the open-source Cloudflare Workers runtime—and can use Durable Objects, D1, KV, and other bindings. [Cloudflare blog] The Astro 6 beta post called this "first-class support for Astro on Cloudflare Workers," with "the same runtime that powers Cloudflare Workers in production—not a simulation or polyfill." Astro 6 also stabilizes Content Security Policy (CSP) support—Astro's most upvoted feature request—and Live Content Collections. [Astro 6 beta]

If you run Astro for content and Cloudflare for the edge, the acquisition and Astro 6 change the day-to-day. Previously, the Astro–Cloudflare integration simulated the Workers runtime during development; you'd deploy and hope behavior matched. With Astro 6, the dev server runs your app in workerd locally—the same runtime as production—so D1, KV, and other bindings behave the same in dev and prod. The Astro 6 beta post: "You can now develop directly against real platform APIs, catching issues during development rather than after deployment." [Astro 6 beta]

At FEDLIN we use both stacks in tandem. For content-driven work—blogs, docs, marketing—we used to choose the build framework per project: Astro was one option alongside others like Next.js, depending on what fit. Given the acquisition and the tradeoffs (one runtime from dev to prod, first-class Workers support, CSP in Astro 6 that pairs with our edge nonce setup), we've opted to standardize on Astro for that class of work. We rely on Cloudflare for Workers, security headers, and dynamic CSP nonce injection at the edge; the security headers scanner we offer is a Cloudflare Worker. The framework and the platform are aligned instead of bolted on. No lock-in: Astro stays MIT-licensed and deployable anywhere; the team building the framework is now inside the company that runs the edge we already use.

We use pnpm across our Astro and Worker projects for speed and strict dependency resolution, which fits our supply-chain and security workflow—we've written about that too. The dev experience is straightforward: hot reload and a live preview without wrestling with tooling.