Astro 6.4's Sätteri: The Rust Markdown Processor That Cuts Build Times — and What You Give Up

Sätteri is Astro 6.4's opt-in Rust Markdown/MDX processor, and yes, it really cuts build times — Astro's own documentation site and the Cloudflare docs site each shaved over a minute off their builds by switching. But it comes with a catch that most summaries bury: Sätteri does not run remark or rehype plugins. And the bigger story of the release is not the speedup at all — it is the new pluggable markdown.processor API that finally ends unified's decade-long monopoly on how Astro renders Markdown.

We write this from a production site that lives exactly in the middle of this trade-off. mintec.co is built on Astro 6.4 with Markdoc for its content collections — more than 750 bilingual content files, service pages, and a pipeline that publishes new articles every morning. Build time is not an abstraction for us; it is a daily CI cost. So when Astro 6.4 shipped on May 28, 2026 with Sätteri, we ran the evaluation properly instead of jumping on the benchmark headline.

What Astro 6.4 actually shipped

The release contained three things, and only one of them got the headlines:

1. A new markdown.processor API — you can now swap the entire Markdown pipeline with a configuration option. The default remains unified(), so existing projects keep working, but your remark/rehype plugins are now configured directly on the processor instead of at the top level.
2. Sätteri (@astrojs/markdown-satteri) — a Markdown and MDX pipeline written in Rust, dramatically faster than the unified-based default, and implementing many Markdown features natively (directives, among others) that previously required plugins.
3. Cloudflare cf() helpers — for the experimental advanced routing added in Astro 6.3, wiring up KV session bindings, the ASSETS binding, and locals.cfContext with one call.

The deprecations are the part teams miss: markdown.remarkPlugins, markdown.rehypePlugins, markdown.remarkRehype, markdown.gfm, and markdown.smartypants still work but are deprecated, and the Astro team has confirmed they will be removed in Astro 8.0. That gives most teams 12 to 18 months at the current release cadence — comfortable, until you realize the migration is trivial today and only grows as your config accumulates customization.

The numbers that matter

Let's put the benchmarks in one place, because the Sätteri story is a numbers story:

Our own number is the one we can defend in a client conversation: a full production build of mintec.co — 756 blog content files across two languages plus service pages, rendered with Markdoc — takes 252 seconds on CI. That is above the threshold where Sätteri starts to matter, and yet the switch would not help us, because Markdoc does not go through the unified pipeline at all. That tension is exactly why the decision framework below exists.

The frequently cited heuristic, from Byteiota's analysis of the Sätteri trade-off: if your build regularly exceeds 80 seconds and your Markdown pipeline is close to vanilla, the switch is straightforward. Below that threshold, the absolute savings are real but rarely worth a pipeline change.

The trade-off table: unified() vs Sätteri

That last row is the one to watch. Astro's release notes explicitly say they hope Sätteri becomes the default Markdown processor in a future major version. If you are on Astro today, you are not deciding whether Sätteri matters — you are deciding when it becomes your default.

Why the processor API matters more than the speedup

Here is the opinion we hold after evaluating this for a real site: the markdown.processor API is the more important change in Astro 6.4, and teams that only see the Rust benchmark are missing the point.

Unified (remark/rehype and friends) has been the de facto standard for Markdown processing in the JavaScript ecosystem for a decade. It is powerful — thousands of plugins — but it is also a monopoly with real costs: a plugin pipeline that processes every Markdown file through layers of JavaScript AST transformations, which is exactly where content-heavy builds spend their time. Sätteri's native implementations (GFM, directives, syntax highlighting primitives) attack that cost at the architecture level, not the optimization level.

But the API is what makes the competition possible at all. Before 6.4, the pipeline was not swappable — you could tune unified, but you could not replace it. Now you can. That is the moment the ecosystem stops being a single point of failure, and it is the reason the porting path exists: Sätteri accepts MDAST/HAST plugins, so plugin authors can target the Rust pipeline without waiting for Astro to change anything.

The practical consequence for teams: the config migration (wrapping plugins in unified({...})) is mandatory work you should do now; the Sätteri switch is optional work you should defer until your plugin list has equivalents.

What this means for a Markdoc-based site like ours

This is where the generic coverage stops being useful, because the most common setup in our corner of the ecosystem — Markdoc for content collections — sits outside the Sätteri story entirely.

Markdoc has its own renderer. It does not go through the markdown.processor API, so Sätteri cannot speed it up and the plugin trade-off does not apply to it. Our site's build time is dominated by rendering 750+ content files with Markdoc and bundling, not by unified's Markdown pipeline. Switching to Sätteri would change nothing for us today — an honest conclusion that most articles about the release do not mention.

That does not mean the release is irrelevant to us. The deprecation timeline is. When Astro 8.0 removes the top-level markdown options, every Astro project — Markdoc or not — has to be on the new configuration model. And the multi-source content strategy we already use on mintec.co means we have more content pipelines than a typical site, which makes the processor choice a recurring decision, not a one-off.

Our evaluation framework, which we would apply to any client site:

The 80-second heuristic from the community analysis holds up in our experience: below it, the Sätteri win is a nice-to-have; above it, especially with vanilla pipelines, it is a genuine infrastructure improvement.

What we are doing, and what we recommend you do

Concrete steps, in order, so this does not become a ticket that sits until Astro 8.0:

1. Run npx @astrojs/upgrade — get onto 6.4.x (or newer) and let the upgrade tool handle the mechanical parts.
2. Wrap your plugins: move remarkPlugins/rehypePlugins into markdown: { processor: unified({ ... }) }. This is the only part that will break at Astro 8.0 — do it before it breaks.
3. Audit your plugin list: count what you actually use. Most sites we audit run 2-4 remark/rehype plugins, and most of those (GFM, directives, smartypants) now have native equivalents in Sätteri.
4. Benchmark your real build: run your production build with timing before and after any switch. The marketing number is "over a minute off docs sites"; your number is what matters.
5. Only then decide on Sätteri — and if you switch, diff the rendered output against unified for edge cases before merging. GFM parsing is spec-compatible, but edge cases can produce minor differences.

We are keeping mintec.co on unified for now, with the config migration done, and re-evaluating when the plugin ecosystem catches up — the same conclusion we reached six months into our Astro + Cloudflare production experience: adopt the platform's direction early, adopt the ecosystem's direction late.

Astro 6.4 did something rare: it shipped a real performance win and an architectural change in the same release. The performance win is Sätteri. The architectural change — a swappable Markdown pipeline — is what will still matter in 2027.

If you are evaluating Astro for a content-heavy or multilingual site, we have been running this stack in production for over a year. We documented the lessons from migrating off WordPress, the real benchmarks against Next.js, and what changed with Astro 7.