Astro 6: the game-changing new features

In short: As of September 5, 2026, migrate from Astro 5 to Astro 6 if you can validate Node.js, adapters, and plugins. The most concrete gains are the production-aligned dev server, Live Content Collections, built-in fonts, and CSP. Test the Rust compiler and Sätteri separately before rolling them out broadly.

Astro 6 is primarily a production-chain upgrade. It brings development closer to the runtime you actually deploy and integrates several needs that previously required custom tooling.

Why does the redesigned dev server matter?

Astro 6 rebuilds astro dev around Vite’s Environment API. The development server and build pipeline share more execution paths, reducing differences between local development and production.

The benefit is especially visible outside Node.js runtimes. For example, the Cloudflare adapter can run workerd during development, prerendering, and production, with platform bindings available locally.

Check before migrating: third-party integrations and adapters may rely on older Vite or Astro APIs. Official integrations have been updated, but every unofficial dependency should be tested on its critical paths.

When should you use Live Content Collections?

Live Content Collections, stabilized in Astro 6, fetch data at request time. They complement build-time collections rather than replacing them.

Use them for a CMS with immediate previews, a catalog whose availability changes frequently, or an API queried with dynamic filters. Keep build-time collections for relatively stable content: they remain easier to cache and better performing.

A live collection is defined in src/live.config.ts:

import { defineLiveCollection } from 'astro:content';
import { z } from 'astro/zod';
import { cmsLoader } from './loaders/cms-loader';

const articles = defineLiveCollection({
  loader: cmsLoader({ apiKey: process.env.CMS_API_KEY }),
  schema: z.object({
    title: z.string(),
    excerpt: z.string(),
  }),
});

export const collections = { articles };

The page then queries the collection with getLiveCollection() or getLiveEntry(). Freshness has a cost: data is loaded at runtime and is not automatically persisted to the content layer data store. MDX and image optimization are not available for live collections.

What does the Fonts API simplify?

The Fonts API unifies local fonts and several providers. Astro downloads and caches the files so your site can serve them, generates optimized fallbacks, and can add the required preload links.

// astro.config.mjs
import { defineConfig, fontProviders } from 'astro/config';

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

You must then place the <Font /> component in the page head and apply the CSS variable. Preload only the fonts needed for immediately visible content: excessive preloading competes with other critical resources.

How does built-in CSP improve security?

Astro 6 stabilizes a Content Security Policy API for static and dynamic pages. A CSP limits which sources are allowed for scripts, styles, images, and other resources, helping reduce the impact of some injections.

// astro.config.mjs
import { defineConfig } from 'astro/config';

export default defineConfig({
  security: {
    csp: true,
  },
});

Astro can compute script and style hashes and generate the corresponding policy. For an application loading external resources, explicitly configure the required directives and inspect the result in the browser. A CSP does not replace proper data escaping or fixing application vulnerabilities.

Should you enable the experimental Rust compiler?

In Astro 6, the Rust compiler remains opt-in. The Astro team describes it as faster, with better diagnostics and improved support for modern JavaScript, TypeScript, and CSS features.

npm install @astrojs/compiler-rs

// astro.config.mjs
import { defineConfig } from 'astro/config';

export default defineConfig({
  experimental: {
    rustCompiler: true,
  },
});

My recommendation: enable it in continuous integration first. The Rust compiler does not automatically correct invalid HTML structure. Unclosed tags or bad nesting can therefore change output or fail the build. In Astro 6, dev toolbar audits are also among its documented limitations.

Is Sätteri compatible with Markdown plugins?

Astro 6.4 adds the markdown.processor API and offers @astrojs/markdown-satteri, a Markdown and MDX processor written in Rust. In this release, unified() remains the default processor to preserve existing compatibility.

Sätteri does not run remark or rehype plugins. If your content depends on those plugins, stay on unified() or port them to Sätteri’s MDAST or HAST interfaces. Do not switch processors solely for a promised faster build: compare rendering, anchors, code highlighting, and your extensions on a representative sample.

Which other features are worth testing?

Astro 6 also ships two experimental features for server rendering:

• Queued Rendering replaces recursive rendering with a two-pass approach. Early benchmarks published by the Astro team reported up to twice the rendering speed on their scenarios.
• Route Caching provides a host-independent API for setting cache duration, stale-while-revalidate, and invalidation tags.

Those results do not guarantee a gain in your application. Measure response time, memory usage, and behavior under load before enabling them in production.

How do you migrate cleanly from Astro 5?

Start with the official upgrade tool:

npx @astrojs/upgrade

Then handle the changes in this order:

1. Node.js: use version 22.12.0 or newer locally and on your hosting platform.
2. Major dependencies: review the Vite 7, Zod 4, and Shiki 4 migrations.
3. Adapters and integrations: update them together and read their changelogs.
4. Content Collections: migrate legacy collections to the Content Layer API; the previous automatic compatibility was removed.
5. Application: verify routes, server rendering, forms, images, and content in staging.

A successful upgrade is more than a green build. Exercise user journeys and the real deployment environment, especially if you use Cloudflare or custom Vite APIs.

Conclusion

Astro 6 is worth the migration for its structural improvements: development closer to production, live data, better integrated fonts, and native CSP. These features solve concrete problems without requiring the Rust compiler or a new Markdown processor.

For an Astro 5 project, I recommend a staged migration: platform and adapters first, stable features next, and Rust experiments separately. You get the benefits of Astro 6 without confusing a necessary upgrade with an optional optimization.

Sources

• Astro 6.0 — official announcement
• Official Astro 6 upgrade guide
• Official Content Collections documentation
• Official Fonts API documentation
• Astro 6 experimental Rust compiler documentation
• Astro 6.4 — Markdown processor and Sätteri