Astro 6 After Cloudflare: Why I Upgraded Now

The Week My Favorite Framework Got Acquired

On January 16, 2026, Cloudflare announced it had acquired The Astro Technology Company, the team behind the Astro web framework. I read the press release on a Friday morning with my coffee going cold. My first thought was not technical. It was a small knot of worry. Every developer who has watched a beloved open source project get bought has felt that same flicker of doubt. Was Astro about to change into something I did not sign up for?

So I did the only thing that actually answers that question. I upgraded a real production site from Astro 5 to Astro 6 and watched what happened. Astro 6 is the first major release shipped under Cloudflare ownership, and it leans hard into edge computing. This is the honest breakdown of what changed, what broke, and whether the move is worth your afternoon.

Key Takeaways

• Cloudflare acquired Astro on January 16, 2026, and Astro stays fully open source under that ownership.
• Astro 6 is edge-first. The rebuilt Cloudflare adapter runs the real Workers runtime in development, prerendering, and production.
• The biggest breaking change is content collections. Legacy collections are gone, so the Content Layer API with loaders is now mandatory.
• Astro 6 requires Node 22.12.0 or later, upgrades to Zod 4, and removes old APIs like Astro.glob and the ViewTransitions component.
• My verdict after upgrading a live site: yes, upgrade. The migration took an afternoon and most of it was mechanical.

What Does Cloudflare Buying Astro Mean for Developers?

It means Astro now has a deep-pocketed owner whose entire business is the edge, and Astro stays open source. Cloudflare confirmed in its announcement that the framework remains open source under its stewardship, so your existing projects keep working and the license does not change.

The practical signal is direction. Cloudflare runs one of the largest edge networks in the world. Owning the framework that compiles your site means Astro and Cloudflare Workers can be designed to fit together instead of being glued together by a community adapter. Astro 6 is the first release where you can feel that intent. The framework is no longer just a static site generator that happens to deploy to the edge. It treats the edge runtime as a first-class target.

Definition: the edge is a network of servers placed physically close to your users, so your code runs near them instead of in one distant data center. Lower distance means lower latency.

What Is New in Astro 6?

Astro 6 is a performance and runtime release. It speeds up builds, redesigns the dev server, and makes non-Node runtimes feel native. Here are the headline changes.

A Dev Server That Runs Your Real Runtime

This is the change I felt first. Astro 6 rebuilds its development server on Vite’s new Environment API. In plain terms, Astro can now run your exact production runtime during development. If you deploy to Cloudflare Workers, your dev server runs on the Workers runtime too. The old curse of “it works in dev but breaks in prod” gets much smaller, because dev and prod stop being two different environments.

A Rebuilt Cloudflare Adapter

The new @astrojs/cloudflare adapter runs workerd, the open source Workers runtime, at every stage. Development, prerendering, and production all use the same engine. You develop directly against Cloudflare platform APIs through the cloudflare:workers module, with full access to your bindings locally. If you live on Cloudflare, this is the single biggest reason to upgrade.

First-Class Content Security Policy

Astro 6 ships first-class Content Security Policy support, which was the most upvoted feature request in the project’s history. You can now define CSP rules through Astro config instead of bolting headers on after the fact. For a content site, that is a real security win with very little effort.

Live Content Collections and Zod 4

Live Content Collections are now stable and out of beta. They let you pull data in real time without rebuilding the whole site, which is useful when your content lives in an external source. Astro 6 also upgrades to Zod 4, the validation library that powers content collection schemas.

An Experimental Rust Compiler

Astro 6 includes an experimental Rust compiler, the successor to the original Go based compiler for .astro files. It is early, but the goal is faster builds. You do not have to enable it, and you should not in production yet, but it signals where build performance is heading.

Astro 5 vs Astro 6 at a Glance

What Breaks When You Upgrade From Astro 5 to 6?

The short answer is content collections, the Node version, and a few removed APIs. Most of it is mechanical find and replace. Here is exactly what I changed on my own site.

First, the content config file moves. Astro 6 expects your collection definitions in src/content.config.ts, not src/content/config.ts. The rename is all that matters, the contents stay the same.

git mv src/content/config.ts src/content.config.ts

Second, the render method changed. In Astro 5 you called entry.render() on the entry object. In Astro 6 you import render from astro:content and call it as a function.

---
// Astro 5
import { getCollection } from "astro:content";
const { Content } = await entry.render();

// Astro 6
import { getCollection, render } from "astro:content";
const { Content } = await render(entry);
---

Third, entry.slug is gone. The Content Layer API exposes entry.id instead, and that id includes the directory and the file extension. I derive the clean slug myself.

// Astro 5
slug: entry.slug,

// Astro 6
slug: entry.id.replace("en/", "").replace(/\.(mdx|md)$/i, ""),

Fourth, the runtime floor moved up. Astro 6 requires Node 22.12.0 or later. I bumped my .nvmrc and the engines field in package.json so local and CI match. If you skip this, your build will fail in continuous integration with a confusing version error.

Astro 6 also removes some long-deprecated APIs. Astro.glob, emitESMImage, and the ViewTransitions component are gone. If your project still uses them, replace them before you upgrade.

One honest note from my migration. The scariest item on every Astro 6 list is the removal of legacy content collections. For me it was a non-event, because this site already used the glob loader from the Content Layer API that arrived in Astro 5. If you migrated your collections back then, the painful part is already behind you. If you are still on type content collections, that is the work that will actually take time.

If you want more context on Astro quirks during real production work, my notes on fixing Astro hydration mismatch errors cover another class of bug you hit once you mix server rendering with islands.

How Do You Upgrade From Astro 5 to Astro 6?

Here is the order I followed, and it worked cleanly on a multilingual content site.

1. Bump your runtime. Set Node 22.12.0 or later in .nvmrc and the engines field.
2. Update Astro and its integrations. I moved astro from 5.17.1 to 6, and bumped @astrojs/react, @astrojs/mdx, @astrojs/sitemap, and @astrojs/partytown to their v6 compatible releases.
3. Rename src/content/config.ts to src/content.config.ts.
4. Replace entry.render() with render(entry) and import render from astro:content.
5. Replace entry.slug with a value derived from entry.id.
6. Remove any usage of Astro.glob, emitESMImage, and ViewTransitions.
7. Run astro check and fix the type errors it surfaces. This step catches almost everything.

If you deploy to Cloudflare Pages, watch your build settings during the upgrade. I have written before about fixing Yarn compatibility issues on Cloudflare Pages build v2, and the same lesson applies here. Pin your package manager and Node version so the build environment matches your local machine.

Frequently Asked Questions

Is Astro 6 worth upgrading to?

Yes for most projects. If you already moved to the Content Layer API in Astro 5, the migration is an afternoon of mechanical changes. If you deploy to Cloudflare, the new adapter alone justifies it.

Is Astro still open source after the Cloudflare acquisition?

Yes. Cloudflare confirmed in its January 16, 2026 announcement that Astro remains open source under its ownership. Your existing projects and license do not change.

Do I have to migrate my content collections for Astro 6?

Yes if you still use legacy type content collections. Astro 5 allowed them through backward compatibility, but Astro 6 removes that. You must use the Content Layer API with loaders.

Does Astro 6 require a Cloudflare account?

No. Astro 6 still builds fully static sites that deploy anywhere. The Cloudflare integration is opt in through the adapter, not a requirement.

What Node version does Astro 6 need?

Node 22.12.0 or later. Update your local runtime and your CI configuration before you upgrade, or your build will fail.

My Verdict After Shipping It

The acquisition fear turned out to be unfounded. Astro 6 is recognizably the same framework, only faster and far more comfortable on the edge. The upgrade cost me an afternoon, most of it spent on a handful of find and replace edits and a Node version bump. The payoff is a dev server that runs my real runtime, first-class CSP, and a Cloudflare story that finally feels intentional instead of bolted on.

If you are still on Astro 5, do the migration now while the changes are small. Start by moving your content collections if you have not already, bump Node to 22.12.0, then let astro check guide you the rest of the way. Have you upgraded yet, or are you waiting it out? I would love to hear how your migration goes.