Astro 6.4 Shipped a Rust Markdown Engine That Halves Build Time — and Quietly Skips Your remark/rehype Plugins. Here's the Honest Upgrade Read.
Astro 6.4 shipped with a new Markdown engine called Sätteri, written from scratch in Rust, and the headline number is the kind that makes you stop scrolling: switching Astro's own documentation site to it shaved more than a minute off the build. The Cloudflare docs site saw a similar cut. That's roughly half the build time gone by changing one config value. This blog runs on Astro, so I read the release the way you probably should: not as a feature recap, but as a "do I migrate my own pipeline this weekend" decision. The answer turns on one detail the announcement is honest about but easy to skim past.
What actually changed
For its entire life, Astro processed Markdown and MDX through the unified ecosystem: remark for Markdown, rehype for HTML, and the long tail of community plugins built on top of them. That ecosystem is flexible and it's also slow, because it's JavaScript doing a lot of tree-walking on every file. On a content site with hundreds or thousands of Markdown files, that cost compounds into the bulk of your build.
Sätteri is a from-scratch Rust Markdown and MDX processor that replaces that pipeline. Astro 6.4 also introduces a new markdown.processor configuration option, which is the real architectural change here: the Markdown pipeline is now pluggable, and Sätteri is the first alternative you can drop in. You install @astrojs/markdown-satteri, point the config at it, and your Markdown stops going through unified.
The speed comes from moving the hot path out of JavaScript. Sätteri parses and transforms in native Rust, and it implements a long list of common Markdown features natively that previously required separate plugins: things like GitHub-flavored tables, footnotes, and syntax highlighting are handled in the engine instead of bolted on. Fewer plugin passes, native execution, big build-time drop.
The catch that decides everything
Here is the line that determines whether any of this applies to you: Sätteri does not run remark or rehype plugins.
That's not a bug, it's the trade. The whole point of a from-scratch Rust engine is that it isn't the unified pipeline, which means it can't load JavaScript plugins written for the unified pipeline. If your content site is vanilla Markdown (posts, headings, code blocks, links, images), you lose nothing, because Sätteri does all of that natively. If your site leans on a stack of remark and rehype plugins, every one of them is something Sätteri either handles its own way or doesn't handle at all.
So the five-minute test is simple: open your Astro config and look at your remarkPlugins and rehypePlugins arrays. If they're empty or close to it, you're a candidate for the full switch today. If they're long (custom directives, reading-time calculators, link decorators, math rendering, diagram embedding, anything bespoke), then migrating means finding native equivalents or doing without, and the 50% build cut comes with a porting bill attached.
This blog, for instance, uses a handful of rehype plugins for code formatting and heading anchors. That's enough that I can't just flip the switch and ship; I'd have to confirm Sätteri covers each one or accept the regression. Which is exactly the kind of thing you want to find out on a branch, not in production.
Whether the build-time win is worth your Saturday
For a solo operator, build time matters in two specific ways, and it's worth being honest about which one you're actually feeling.
The first is CI cost and deploy latency. If your content site rebuilds on every push and you're sitting through multi-minute deploys, cutting that in half is real quality of life and, on metered CI, real money. A site that takes two minutes to build and deploys ten times a day is twenty minutes of waiting daily; halving it is the kind of small compounding win that's worth one focused session to set up.
The second is local development, and here the gain is smaller than the headline suggests, because Astro's dev server already does incremental work: you're not rebuilding the whole site on every save. The minute-plus number is a full production build, not your edit-refresh loop. If your complaint is that astro dev feels sluggish, Sätteri helps less than you'd hope.
So the honest read: if you run a content-heavy Astro site with a near-empty plugin list and you deploy often, try Sätteri on a branch this weekend: the upside is concrete and the migration is a config change. If your plugin list is long, the right move is to read what Sätteri covers natively, map each plugin to a native feature or a deliberate drop, and only then decide. And if you're on a small site that builds in twenty seconds and deploys twice a week, this is a fun number that changes nothing for you, and you should spend the Saturday on something that moves revenue.
The honest take
The thing I actually like about Astro 6.4 isn't the Rust engine. It's the markdown.processor option underneath it. Making the Markdown pipeline pluggable means the unified-vs-native question stops being all-or-nothing at the framework level and becomes a per-project choice. That's the right design. Sätteri is the first beneficiary, but the real win is that swapping the engine is now a supported move instead of a fork.
Where I could be wrong: native-engine Markdown processors have a way of being 95% compatible and then biting you on the 5%: some edge case in how a table renders, some whitespace handling that differs from unified, some plugin behavior you didn't know you depended on until a page looks wrong. Rust speed is not worth a content site that subtly mis-renders, and you won't catch every difference by spot-checking your homepage. If you migrate, diff a real sample of built pages against the old output before you merge, not just the three you remember to look at. The build-time number is the easy part to verify. The rendering fidelity is the part that decides whether the upgrade was a good idea.
Author
Lukas
@lukcombinator