Astro 6 is here! Astro 6 introduces a broad set of new capabilities, including a built-in Fonts API, Content Security Policy API, and support for Live Content Collections that work with your externally-hosted content through the unified Astro content layer.

Alongside these new features, we also completed a major refactor of the Astro dev server and much of the build pipeline. Powered by Vite’s new Environment API, Astro can now run your exact production runtime during development. That means fewer “works in dev, breaks in prod” surprises — especially on non-Node.js runtimes like Cloudflare Workers, Bun, and Deno.

Full release highlights include:

• A redesigned astro dev
• Improved Cloudflare support
• Built-in Fonts API
• Live Content Collections
• Content Security Policy
• Upgraded Packages
• Experimental: Rust Compiler
• Experimental: Queued Rendering
• Experimental: Route Caching
• Community

One more thing: Astro 6 includes an experimental new Rust compiler — the successor to our original Go-based .astro compiler. It’s still early, but the results are already impressive (and in some cases, even more reliable than our current Go compiler). We’ll continue to invest in Rust-powered tooling throughout the 6.x release line to improve performance and scalability for large sites.

Upgrade now

To upgrade an existing project to Astro 6, use the automated @astrojs/upgrade CLI tool:

# Recommended:
npx @astrojs/upgrade
# Manual:
npm install astro@latest

For new projects, simply use:

A redesigned astro dev

Astro’s dev server was originally built for Node.js — and for most Astro users, that worked great. But as non-Node runtimes like Cloudflare Workers, Bun, and Deno gained traction, that assumption became a blind spot. Developers targeting these platforms had no way to run their actual production runtime during development, so the behavior you saw locally didn’t always match what you shipped.

Astro 6 changes that. By leveraging Vite’s new Environment API, astro dev can now run a custom runtime environment during development. The dev server and build pipeline now share the same code paths, unifying your development experience with production.

For Cloudflare users, this gap was especially painful. The dev server ran on Node.js, but production ran on Cloudflare’s workerd runtime. Bugs only showed up after the deploy. Cloudflare bindings — KV, D1, R2, Durable Objects — weren’t available during development at all. You were coding blind and hoping it would work in production.

The rebuilt @astrojs/cloudflare adapter now runs workerd at every stage: development, prerendering, and production. You develop directly against Cloudflare’s platform APIs using cloudflare:workers, with full access to your bindings locally. No more simulation layers, and no more Astro.locals.runtime workarounds. This work grew out of our official partnership with Cloudflare announced last year, with the goal of making Cloudflare a first-class Astro runtime.

Built-in Fonts API

Almost every website uses custom fonts, but getting them right is surprisingly complicated. There are performance tradeoffs, privacy concerns, and a dozen small decisions that are easy to get wrong.

Astro 6 adds a built-in Fonts API that takes care of the hard parts for you. You configure your fonts from local files or providers like Google and Fontsource, and Astro handles the rest: downloading and caching for self-hosting, generating optimized fallbacks, and adding preload links — keeping your site fast and your users’ data private.

To get started, configure a fonts object with one or more fonts that you’d like to use in your project:

import { defineConfig, fontProviders } from 'astro/config';
export default defineConfig({
  fonts: [
    {
      name: 'Roboto',
      cssVariable: '--font-roboto',
      provider: fontProviders.fontsource(),
    },
  ],
});

Then, add a <Font /> component and styling wherever you need it — a global layout, a single page, or a specific section of your site:

---
import { Font } from 'astro:assets';
---
<Font cssVariable="--font-roboto" preload />
<style is:global>
  body {
    font-family: var(--font-roboto);
  }
</style>

Behind the scenes, Astro downloads the font files, generates optimized fallback fonts, and adds the right preload hints — so you get best-practice font loading without configuring it yourself.

To learn more, check out the fonts guide.

Live Content Collections

Live Content Collections are now stable in Astro 6, bringing request-time content fetching to Astro’s unified content layer.

Content Collections have been a core part of Astro since 2.0. But they’ve always required a rebuild when content changed. Live Content Collections fetch content at request time instead, using the same APIs, with no rebuild step required. Your content updates the moment it’s published, without touching your build pipeline. That means CMS content, API data, and editorial updates all go live instantly.

Use defineLiveCollection() to define a live source in src/live.config.ts:

import { defineLiveCollection } from 'astro:content';
import { z } from 'astro/zod';
import { cmsLoader } from './loaders/my-cms';
const updates = defineLiveCollection({
  loader: cmsLoader({ apiKey: process.env.MY_API_KEY }),
  schema: z.object({
    slug: z.string(),
    title: z.string(),
    excerpt: z.string(),
    publishedAt: z.coerce.date(),
  }),
});
export const collections = { updates };

Then query live content in your page with built-in error handling:

---
import { getLiveEntry } from 'astro:content';
const { entry: update, error } = await getLiveEntry(
  'updates',
  Astro.params.slug,
);
if (error || !update) {
  return Astro.redirect('/404');
}
---
<h1>{update.data.title}</h1>
<p>{update.data.excerpt}</p>
<time>{update.data.publishedAt.toDateString()}</time>

Live Content Collections use the same familiar APIs as build-time collections (getCollection(), getEntry(), schemas, loaders), so there’s no new mental model to learn. If your content needs real-time freshness, define a live collection with a live loader and your content goes live on every request. If it doesn’t, keep using build-time collections for the best performance. Both can coexist in the same project.

For more on live content collections, see the content collections guide.

Content Security Policy

Astro’s Content Security Policy API is now stable in Astro 6. Astro is one of the first JavaScript meta-frameworks to offer built-in CSP configuration for both static and dynamic pages, in both server and serverless environments.

CSP is deceptively hard to implement in a framework like Astro. It requires knowing every script and style on a page so they can be hashed and included in the policy. For static pages, that can be computed at build time. But for dynamic pages, content can change per request — which means hashing on the fly and injecting the right headers at runtime. Supporting both modes in a single, unified API is why no other meta-framework has done this before.

Getting started is simple. Enable CSP with a single flag, and Astro handles the rest — automatically hashing all scripts and styles in your pages and generating the appropriate CSP headers:

import { defineConfig } from 'astro/config';
export default defineConfig({
  security: { csp: true },
  experimental: { csp: true },
});

That’s all you need for most sites. When you need more control — custom hashing algorithms, additional directives for external scripts or styles — the full configuration API is available:

import { defineConfig } from 'astro/config';
export default defineConfig({
  security: {
    csp: {
      algorithm: 'SHA-512',
      directives: [
        "default-src 'self'",
        "img-src 'self' https://images.cdn.example.com",
      ],
      styleDirective: { hashes: ['sha384-styleHash'] },
      scriptDirective: { hashes: ['sha384-scriptHash'] },
    },
  },
});

As part of this stabilization, CSP also works with Astro’s responsive images out of the box. Responsive image styles are calculated at build time and applied using CSS classes and data-* attributes, so they can be hashed and included in your CSP policy automatically — no extra configuration needed.

See the security configuration reference for full details.

Upgraded Packages

Astro 6 includes major upgrades to several core dependencies:

• Vite 7 is now used across Astro and all @astrojs packages. If your project pins a custom Vite version, update it to v7 or later before upgrading.
• Shiki 4 now powers code highlighting in the <Code /> component and Markdown/MDX code blocks.
• Zod 4 now powers content schema validation. When defining schemas, import Zod from astro/zod rather than astro:content.

Astro 6 also now requires Node 22 or later, dropping support for Node 18 and Node 20, which have reached or are approaching end-of-life. Node 22 is faster, more secure, and lets us drop polyfills for older Node versions — resulting in a smaller, more maintainable package and better performance in Astro across the board.

See the upgrade guide for detailed migration steps.

Experimental: Rust Compiler

Astro 6 includes an experimental new Rust compiler — the successor to our original Go-based .astro compiler.

What started as an AI experiment while updating our Go compiler for Astro 6 quickly moved from “can this work?” to “why isn’t this the default?” The new compiler is faster, produces stronger diagnostics, and in some cases is even more reliable than our current Go compiler. We hope to make it the default in a future major release.

You can try it today by enabling the rustCompiler flag and installing the @astrojs/compiler-rs package:

npm install @astrojs/compiler-rs

import { defineConfig } from 'astro/config';
export default defineConfig({
  experimental: {
    rustCompiler: true,
  },
});

We’re actively exploring more Rust-powered tooling across Astro, with more to share soon.

Read our reference documentation on the Rust compiler for more details.

Experimental: Queued Rendering

Astro 6 introduces an experimental new rendering strategy, with early benchmarks showing up to 2x faster rendering.

Today, Astro renders components recursively. Rendering functions call themselves as they walk the component tree. Queued rendering replaces this with a two-pass approach: the first pass traverses the tree and emits an ordered queue, then the second pass renders it. The result is both faster and more memory-efficient, and we plan to make it the default rendering strategy in Astro v7.

Try it today by enabling the experimental flag:

import { defineConfig } from 'astro/config';
export default defineConfig({
  experimental: {
    queuedRendering: {
      enabled: true,
    },
  },
});

See the experimental queued rendering documentation for more on this feature, including additional options like node pooling and content caching.

Experimental: Route Caching

Astro 6 includes an experimental route caching API that gives you a platform-agnostic way to cache server-rendered responses using web standard cache semantics.

Caching SSR responses today is harder than it should be. Every host does it differently, and there’s no standard way to control it from your application code. Route caching gives you a single, platform-agnostic API: set caching directives in your routes, and Astro handles the rest regardless of where you deploy.

Enable route caching by configuring a cache provider in your Astro config. A cache provider tells Astro where to store cached responses. Astro ships with a built-in memoryCache provider to get you started:

import { defineConfig } from 'astro/config';
import { memoryCache } from 'astro/config';
export default defineConfig({
  experimental: {
    cache: { provider: memoryCache() },
  },
});

Then use Astro.cache (or context.cache, in API routes) to control caching per-request. You can set cache duration, stale-while-revalidate windows, and tags for targeted invalidation. In this example, we set the cache headers for the response, customized to the request:

---
Astro.cache.set({
  maxAge: 120, // Cache for 2 minutes
  swr: 60, // Serve stale for 1 minute while revalidating
  tags: ['home'], // Tag for targeted invalidation
});
---
<html><body>Cached page</body></html>

This is where Astro’s unified content layer really shines. Route caching integrates directly with live content collections, automatically tracing dependencies between pages and content entries. When a content entry changes, any cached responses that depend on it are invalidated automatically:

import { getEntry } from 'astro:content';
const product = await getEntry('products', Astro.params.slug);
// When the product changes, Astro will invalidate this cached page:
Astro.cache.set(product);

This initial release includes a simple in-memory cache provider, which works best with the Node.js adapter. We will be adding cache providers for all of Astro’s supported deployment platforms in the next few weeks. We also hope there will be community-built providers for CDN services, and other storage types such as Redis. Get in touch on Discord if you’re interested in building one!

For more details, see the experimental route caching docs.

The Astro core team is:

Alexander Niebuhr , Armand Philippot , Chris Swithinbank , Emanuele Stoppa , Erika , Florian Lefebvre , Fred Schott , HiDeoo , Luiz Ferraz , Matt Kane , Matthew Phillips , Reuben Tier , Sarah Rainsberger , and Yan Thomas .

Special thanks to everyone who contributed to Astro 6 with code, docs, reviews, and testing, including:

0xRozier, Abdelrahman Abdelfattah, Adam Matthiesen, Adrian, ADTC, Ahmad Yasser, Alasdair McLeay, Alejandro Romano, Alex, Alex Launi, Andreas Deininger, Andrey, Andrey Gurtovoy, andy, Antony Faris, Ariel K, Aron Homberg, Ash Hitchcock, Azat S., Bartosz Kapciak, Brian Dukes, btea, Cameron Pak, Cameron Smith, cid, CyberFlame, Danilo Velasquez Urrutia, Darknab, Deleted user, Deveesh Shetty, Dom Christie, Dominik G., Dream, Drew Powers, Edgar, Edward Brunetiere, ellielok, Eric Grill, Eryk Baran, everdimension, fabon, Felix Schneider, fkatsuhiro, Fred K. Schott, Fredrik Norlin, Gokhan Kurt, Henri Fournier, Hunter Bertoson, Ibim Braide, Jack Platten, Jack Shelton, James Garbutt, James Opstad, Jeffrey Yasskin, jmgala, joel hansson, Johan Rouve, John L. Armstrong IV, John Mortlock, Jonas Geiler, Josh Soref, Julián Colombo, Julian Wolf, Julien Cayzac, Junseong Park, Justin Francos, kato takeshi, Kedar Vartak, Kendell, Kevin Brown, knj, Koos Looijesteijn, Kristijan, KTrain, ktym4a, Lieke, Light, Louis Escher, Luky Setiawan, Mads Erik Forberg, Manuel Meister, Mark Ignacio, Martin Trapp, Matheus Baroni, Matthew Conto, Matthew Justice, Maurici Abad Gutierrez, Mehdi El Fadil, Michael Payne, Michael Stramel, Mike Pagé, MkDev11, Morten Oftedal, nemu, Ntale Swamadu, Ocavue (Jiajin Wen), Olcan EBREM, Oliver Speir, Olivier Dusabimana, Patrick Arlt, Phaneendra, Philippe Serhal, Raanelom, Rafael Yasuhide Sudo, Rahul Dogra, randomguy-2650, Razon Yang, Robin Bühler, Roman, Roman Hauksson-Neill, Roman Kholiavko, sanchezmaldonadojesusadrian14-coder, Sebastian Beltran, Shinya Fujino, Simen Sagholen Førrisdal, Stel Clementine, Steven, Tanishq Manuja, Tee Ming, Timo Behrmann, Tony Narlock, Umut Keltek, Varun Chawla, Victor Berchet, Vladyslav Shevchenko, Volpeon, Willow (GHOST), Xidorn Quan, Yagiz Nizipli, yy, 五月七日千緒, and 翠

We hope you enjoy Astro 6. If you run into issues or want to share feedback, please join us on Discord, post on GitHub, or reach out on Bluesky, Twitter, and Mastodon.