Is it worth upgrading to Astro 7 right away?

If your project uses no remark/rehype plugins and no astro:db, the upgrade is low-risk and quick - there is little reason to wait. The build speedup scales with project size: on a 22-second baseline it is a pleasant 11 seconds saved, on multi-minute CI builds it adds up to real cost and deploy-time savings.

What is the biggest breaking change in Astro 7?

For most projects, the Markdown processor switch: Sätteri (Rust) replaces the unified pipeline as the default. If you rely on remark or rehype plugins, you have to install and configure @astrojs/markdown-remark explicitly. Without custom Markdown plugins, Sätteri renders GitHub-Flavored Markdown including tables and inline HTML unchanged.

Do I have to change my code for the new Rust compiler?

Only if it contains invalid HTML. The compiler rewritten in Rust no longer silently fixes broken markup: unclosed elements such as an open p tag now cause a build error instead of an auto-correction. Valid HTML passes without any changes.

What is the whitespace change in Astro 7 about?

The default value of compressHTML changes from true to 'jsx'. Whitespace between elements is stripped more aggressively - in the worst case two inline elements end up glued together in the visible text. Whether your project is affected is shown by comparing the rendered text (innerText) between the old and new version. If you need the old behaviour, set compressHTML: true in the config.

Upgrading to Astro 7 in practice: build time halved, zero code changes

Major framework versions have a reputation: read the changelog first, then block out the weekend. Astro 7 is the opposite. I migrated this website - Astro 6.3, SSR with the Node adapter, Svelte 5, Tailwind 4, bilingual routing, around 35 blog posts in content collections - to Astro 7.0. Effort: one npm command. Code changes: zero. Result: build time halved.

Astro 7 shipped on 22 June 2026, and real-world migration reports are still thin on the ground. So here is the full field report: what Astro 7 changes technically, what numbers a real project produces, which breaking changes affect whom - and how to test the one underrated trap properly.

What Astro 7 brings

Astro 7 is, at its core, a performance release. Three big rewrites, all in Rust:

Rolldown instead of Rollup: Astro 7 moves to Vite 8, and with it to Rolldown - the Rust-based bundler replacing Rollup, which the Vite team benchmarks at 10 to 30 times faster bundling.
A Rust compiler for .astro files: The previous Go-based compiler has been completely rewritten in Rust and is now the only option.
Sätteri as the Markdown processor: The unified pipeline (remark/rehype) is no longer the default. Sätteri processes Markdown in Rust, GitHub-Flavored Markdown included.

On top of that, queued rendering - experimental in Astro 6 - is now the default, with up to 2.4x faster rendering of many pages according to the Astro team. In total, Astro promises 15 to 61 percent faster builds, with some sites more than doubling.

Marketing numbers. What a real project measures is more interesting.

The upgrade: one command, no drama

The starting point was Astro 6.3.3. Instead of npx @astrojs/upgrade (which prompts interactively), I pulled the packages directly:

npm install astro@latest @astrojs/node@latest @astrojs/svelte@latest @astrojs/sitemap@latest

The result in the dependency tree: astro 7.0.6, @astrojs/node 11, @astrojs/svelte 9 - and npm reports 77 removed packages against only 17 new ones. The tree gets noticeably leaner because the Rust toolchain replaces entire JavaScript subtrees.

Then: npm run build. No config rework, no codemod, not a single fix. The build passed on the first attempt - including Svelte 5 islands, the Tailwind 4 Vite plugin, i18n routing with fallbacks, middleware with redirect logic and a dynamic sitemap. A major upgrade of an entire framework being this uneventful is rare enough to be worth writing down.

How you can tell Rolldown is really doing the work: the familiar chunk-size warning no longer points to build.rollupOptions but to build.rolldownOptions.

The numbers: build time halved

Measured on the same machine (Windows, Node 22), two runs each with a warm cache, identical project state:

Measurement	Astro 6.3.3	Astro 7.0.6	Delta
Total build (`npm run build`)	21.5 s / 22.7 s	10.9 s / 11.2 s	approx. -50 %
of which “Server built”	19.9 s	8.1 s	-59 %

That puts this project at the upper end of Astro’s promised 15 to 61 percent. For context: it is a mid-sized SSR project - about 60 routes (two languages), two content collections, Three.js and Svelte islands. Purely static sites with lots of Markdown pages should benefit even more from Sätteri and queued rendering.

Whether 11 saved seconds matter depends on context. Locally, it is comfort. In CI and deployment, it is money: every push to main rebuilds this project in a container - half the build time means half the wait until rollout and fewer server resources tied up. For projects whose builds run into minutes, comfort turns into an argument.

Breaking changes, reality-checked

The official list is short. What matters is who each item actually hits:

Sätteri instead of remark/rehype. If you use custom remark or rehype plugins (footnotes, custom directives, special syntax-highlighting setups), you only get the old pipeline back by installing and configuring @astrojs/markdown-remark explicitly. This project uses no Markdown plugins - and Sätteri rendered all content identically, GFM tables and inline HTML in the articles included. I verified that instead of assuming it (more below).

A stricter compiler. The Rust compiler no longer silently fixes invalid HTML. An unclosed  used to be auto-corrected; now it is a build error. That is an improvement - silent auto-fixing is a source of bugs, not a feature - but projects with organically grown templates should treat the first build as a diagnostic run.

@astrojs/db is gone. If you use Astro DB, you need a migration plan (Node’s built-in SQLite, Drizzle, or an external database). For everyone else: irrelevant.

src/fetch.ts is reserved. That file now belongs to the new advanced routing. If you happen to have your own file by that name, rename it.

Vite 8. Custom Vite plugins should be compatible with Vite 8. The Tailwind 4 plugin ran without a hitch here.

The whitespace trap - and how to test for it

The most inconspicuous changelog entry has the biggest surprise potential: the default of compressHTML changes from true to 'jsx'. Astro now strips whitespace between elements far more aggressively. In this site’s raw HTML, hundreds of spaces between tags are gone after the upgrade - the homepage got about 1 KB smaller.

The problem: between block elements, stripped whitespace is harmless; between inline elements, it is not. Hello world can turn into “Helloworld” in the visible text. Whether it hits your project is decided by your markup, not by the changelog.

So I measured instead of hoping: opened the old version (live) and the new version (local) in a browser, extracted document.body.innerText from each, normalised whitespace, compared word lists. Result here: identical word for word, on the homepage and in blog articles. In this project the compression only touches whitespace between block elements.

If your diff is not empty: compressHTML: true in astro.config restores the old behaviour; a targeted {" "} at the affected spots is the cleaner fix.

My upgrade checklist

This was the complete procedure - transferable to any Astro project:

Upgrade in a git worktree, not in your main checkout. git worktree add ../project-astro7 main gives you an isolated copy; ongoing work stays untouched.
Measure a baseline. Time npm run build twice on the old version. Without a before value, every speedup claim is a guess.
Pull the packages: astro@latest plus all @astrojs/* integrations in one go.
Treat the first build as a diagnostic run. Errors from the stricter compiler surface here, not in production.
Smoke-test the core routes. Start the production build and check the most important URLs for status 200 - on SSR projects including middleware redirects and i18n routes.
Run an innerText diff against the live version for the whitespace trap (see above).
Spot-check Markdown: one article with tables and inline HTML, rendered once on the old and once on the new version.

Steps 1 through 7 took less than an hour in total. Most of that was measuring, not fixing.

Conclusion

Astro 7 is that rare major release where the benefit is immediately measurable and the migration cost is close to zero - as long as your project uses no remark plugins and no Astro DB. Build time halved, 77 fewer packages in the tree, identical rendering. If you are on Astro 6, waiting costs you nothing dramatic - but upgrading saves you build time every single day.

And if you are currently deciding what a new website should be built on: releases like this are exactly why I use Astro for business websites - the framework gets faster every year without existing projects having to be rebuilt for it.

Transparency: the measurements come from upgrading this very website on 5 July 2026. Different projects, different numbers - which is why the methodology is included.