Astro 7.0: The Rust Compiler, Vite 8, and What Actually Breaks

Astro 7.0 landed on June 22, 2026, and unlike most major version bumps, it barely touches the API you write against. The headline changes are underneath: the compiler is now Rust instead of Go, the bundler is Vite 8 instead of Vite 7, and the markdown parser we covered as an opt-in in Astro 6.4 is now the default. If you don’t use @astrojs/db and don’t have a pile of custom Vite plugins, the upgrade is closer to a version bump than a rewrite.

The toolchain rewrite

Astro’s compiler, the piece that parses .astro files and turns them into HTML and JavaScript, has been rewritten in Rust. The previous implementation was written in Go and compiled to WebAssembly for use in Node; the new one is native Rust, also shipped as WASM where needed. Astro’s team frames this as a foundations release rather than a features release, and that’s the right way to read it: nothing about component syntax, props, or slots changed. What changed is the machinery that processes them, which is where a Rust rewrite of a hot path in every build typically pays off over time as the team optimizes it further.

Alongside the compiler, Astro 7.0 moves the dev server and production bundler to Vite 8. For application code, this is close to invisible; Vite’s own breaking changes between 7 and 8 are aimed at plugin authors and tools that reach into Vite internals, not at code that just imports and renders. If you maintain an Astro integration or a Vite plugin as part of your stack, that’s the surface to test. If you consume integrations from the ecosystem, wait for your key dependencies (adapters, UI framework integrations) to confirm Vite 8 compatibility before upgrading a production site, the same way you’d wait out any major bundler bump.

Sätteri is now the default markdown parser

Astro 6.4 introduced Sätteri, a Rust-based markdown and MDX processor, as an opt-in alternative to the long-standing unified() pipeline built on remark and rehype plugins. In 7.0, Sätteri becomes the default. The tradeoff is the same one we flagged when it shipped: Sätteri doesn’t execute remark or rehype plugins, so projects with custom markdown transforms (a remark-toc, a custom heading-ID plugin, anything from the unified ecosystem) will silently lose that processing unless they explicitly opt back into unified():

// astro.config.mjs
export default defineConfig({
  markdown: {
    processor: "unified", // opt back into remark/rehype plugins
  },
});

Sites with plain markdown and no custom plugins won’t notice the switch beyond faster builds. Sites with a customized pipeline should check their build output against the previous version before shipping, since a plugin silently not running is easy to miss until a reader points out a broken table of contents.

What actually got removed

This is the part of the upgrade that needs planning, not just testing. Three things are gone outright, not deprecated-with-a-warning:

Removed	What it means
@astrojs/db	If your project used Astro DB’s hosted SQLite database, you need a replacement (self-hosted SQLite/Postgres, Turso, or another provider) before upgrading, not after
astro db, astro login, astro logout, astro link CLI commands	These commands no longer exist; scripts or CI steps that call them will fail
Deprecated astro:transitions APIs	Older View Transitions APIs superseded in earlier 6.x releases are now gone; projects still on the old API need to move to the current View Transitions implementation first

If none of these apply to your project, this table is the whole migration. If any of them do, budget time before you touch the version number, because there’s no compatibility flag to fall back on.

The Node.js floor moved to 22

Astro 7.0 requires Node.js 22 as a minimum. This is the kind of requirement that’s easy to miss in a changelog and then hit as a cryptic install failure in CI. Check your CI runner’s Node version and your local environment before upgrading the package:

node --version   # needs to report v22.x or newer

If you’re on Node 18 or 20, upgrade the runtime first, verify your existing test suite still passes on the new Node version, and only then bump Astro. Rolling both changes into one PR makes it harder to tell which change caused a given failure.

Whitespace handling changed by default

compressHTML now defaults to JSX-style whitespace handling: line breaks and whitespace between elements in your markup get stripped, matching the convention React and several other frameworks already use. For the overwhelming majority of layouts this is invisible. It’s worth an explicit check if any part of your site relies on literal whitespace between inline elements for visual spacing, since that’s exactly the pattern this change affects. A preview build with a visual diff against production, or even a manual scroll through your most whitespace-sensitive pages, catches this quickly.

A practical upgrade checklist

1. Confirm Node.js 22+ in local dev and CI before changing anything else.
2. Search the codebase for @astrojs/db imports and any astro db/astro login calls in scripts or CI config. Replace before upgrading if found.
3. If you use custom remark or rehype plugins, either verify they still matter after the Sätteri default switch, or explicitly set markdown.processor: "unified" to keep them running.
4. Check any Vite plugins or Astro integrations you depend on for stated Vite 8 compatibility.
5. Do a visual pass on whitespace-sensitive inline layouts after upgrading, before merging.
6. Run npx @astrojs/upgrade (or your package manager’s equivalent) and let Astro’s own upgrade tooling flag anything project-specific it detects.

For a site that’s plain markdown, no @astrojs/db, and no custom Vite internals, that checklist takes fifteen minutes. For a site with any of the three removed features in active use, treat the removal work as its own task before scheduling the version bump. Either way, this is a foundations release worth taking seriously even though it changes almost nothing you’ll actually write: a faster compiler and a current bundler under an unchanged component model is the upgrade you actually want, and it’s a good one to plan into your next sprint rather than defer indefinitely.