Astro 6: a dev server on Vite's Environment API, local workerd and a Rust compiler

Astro 6.0 came out on March 10, and I have a personal stake in this release: the blog you are reading is built with Astro. So I read the notes with double the attention, both for what changes for the ecosystem and for what will change here with the next upgrade.

A dev server that looks more like production

The deepest change does not show up as any new API. Astro’s dev server was rewritten on top of Vite’s Environment API, which lets astro dev run a custom runtime environment. According to the team, development and build now share the same code paths, so local behavior gets much closer to what ships to production.

The people who benefit most, right away, are those deploying to Cloudflare. The @astrojs/cloudflare adapter was rebuilt and now runs workerd, the Workers runtime, in development, prerendering and production. In practice, you can use the cloudflare:workers APIs locally, with bindings for KV, D1, R2 and Durable Objects. The Astro.locals.runtime workarounds are no longer needed. To me, this is the kind of change that removes an entire category of “works on my machine” bugs.

Fonts, live content and CSP

Astro 6 gained a built-in Fonts API. You declare fonts in a fonts array in astro.config, using providers such as Google or Fontsource, and use the <Font /> component from astro:assets, which takes a cssVariable prop and an optional preload flag. Astro downloads and self-hosts the files, generates optimized fallbacks and adds the preload hints. It is a tedious job almost every site does by hand, and it is great to see the framework handle it.

Live Content Collections are now stable. They fetch content at request time, with no rebuild needed when the data changes. They are defined with defineLiveCollection() in src/live.config.ts, use the same APIs as build-time collections and can coexist with them. getLiveEntry() returns an object with entry and error, which forces you to handle failures explicitly.

The Content Security Policy API also left experimental status. Turn on security.csp in the config and Astro hashes scripts and styles automatically, on both static and dynamic pages. There are advanced options such as algorithm, directives, styleDirective and scriptDirective.

Dependencies and what might break

This is where the migration work lives. Astro 6 uses Vite 7 across all @astrojs packages, so anyone who pinned their own Vite version needs to move to 7 or later. Syntax highlighting now uses Shiki 4, and content schemas use Zod 4, which should be imported from astro/zod.

And the point most likely to catch people off guard: Astro 6 requires Node 22 or later. Support for Node 18 and Node 20 was dropped. If your CI or hosting still runs Node 20, that is the first item on the list.

The experiments that point to the future

Three experimental features show where the project is heading:

• Rust compiler: a successor to the Go-based compiler for .astro files. You enable it with the rustCompiler flag under experimental and by installing the @astrojs/compiler-rs package. The team says it hopes to make it the default in a future major release.
• Queued rendering: replaces recursive component rendering with a two-pass approach that first builds an ordered queue from the tree and then renders it. According to the team’s early benchmarks, rendering gets up to 2x faster. The plan is for it to become the default in Astro 7.
• Route caching: a platform-agnostic API for caching server-rendered responses using web standard cache semantics. Per request, you use Astro.cache to set maxAge, swr and tags, and the integration with live collections lets you invalidate pages when content changes.

My take

Astro 6 is more of a foundation release than a showcase one. Rewriting the dev server on Vite’s Environment API is the kind of work users only notice when they stop getting surprises between local and production. For anyone on Cloudflare, it is probably the best Astro upgrade in a long time.

For a static site like this one, the immediate gains are more modest: the Fonts API and stable CSP are welcome, and queued rendering may shorten builds down the road. The real cost is the Node 22 requirement and the Vite and Zod upgrades, which can break plugins and schemas. My advice is simple: check the Node version in your pipeline before anything else, then upgrade calmly, keeping an eye on your content schemas.