Astro 6.4: The Rust Markdown Processor That Cuts Build Times, and What You Give Up to Use It

Astro 6.4 shipped in late May 2026, and the headline feature is a markdown pipeline that, for the first time, you can actually swap out. The default is still unified(), the same JavaScript-based remark/rehype pipeline Astro has always used, so nothing breaks if you do nothing. But there’s now a real alternative for the specific case where markdown processing is your build-time bottleneck.

What actually shipped

Astro 6.4 introduces a markdown.processor config option. Set it, and Astro routes markdown and MDX compilation through whichever processor you choose instead of the built-in pipeline.

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

export default defineConfig({
  markdown: {
    processor: 'satteri', // opt into the new Rust pipeline
  },
});

The processor being offered alongside the default is Sätteri, shipped as a new @astrojs/markdown-satteri package. It’s a Rust-native markdown and MDX pipeline, and its whole reason for existing is speed: it implements GFM tables, footnotes, smart punctuation, and syntax highlighting hooks natively, rather than assembling them from a chain of separate remark plugins.

Why that matters for performance: every plugin in a unified() pipeline walks the full abstract syntax tree of your document. Five plugins means five traversals of the same content, even if each individual plugin does very little work. Sätteri collapses that into a single native pass. The more plugins your unified config chains together, the more this compounds, which is exactly why the biggest wins show up on the biggest sites.

The numbers Astro published

Astro’s team benchmarked the switch on their own infrastructure rather than a synthetic test case, and reported the results in the 6.4 release post: switching both the Astro documentation site and the Cloudflare documentation site to Sätteri shaved over a minute off each site’s respective build time.

That’s a meaningful number for two reasons. First, it’s a real production workload, not a contrived benchmark. Second, both are large, markdown-heavy docs sites, which is the profile where a faster processor pays off most. If you’re running a five-page marketing site, don’t expect the same absolute savings. If you’re running a documentation site with hundreds of pages and a plugin chain doing GFM parsing, syntax highlighting, table of contents generation, and heading-anchor injection, the maths favor Sätteri clearly.

What you give up

Sätteri’s speed comes from not running the unified plugin ecosystem. If your astro.config.mjs currently lists remarkPlugins or rehypePlugins, none of them execute under Sätteri. Common cases that will need a decision:

If your project uses…	Sätteri support
Standard GFM tables, footnotes, smart quotes	Native, works out of the box
Syntax highlighting via Shiki	Supported via built-in hooks
Custom remark/rehype plugins (TOC generators, link rewriters, etc.)	Not executed, so stay on unified() or port the plugin
MDX components	Unaffected, MDX component handling is separate from markdown text processing

For teams with a plugin-free or lightly customized pipeline, switching costs one config line and a test build. For teams with several custom plugins doing real work (link validation, custom callouts, cross-reference generation), staying on unified() for now is the reasonable call. Astro isn’t forcing a migration: the legacy config keys (markdown.remarkPlugins, rehypePlugins, remarkRehype, gfm, smartypants) still work, they’re just marked deprecated with removal planned for Astro 8.0, which gives teams real runway.

Trying it on this kind of site

This blog itself is served from a set of markdown files staged into an Astro site, which is exactly the workload Sätteri targets: hundreds of posts, syntax-highlighted code blocks, and standard GFM tables, with no exotic remark plugins in the pipeline. That combination is close to the best case for switching, and it’s worth testing in a branch before committing to it project-wide.

npm install @astrojs/markdown-satteri

// astro.config.mjs
export default defineConfig({
  markdown: {
    processor: 'satteri',
  },
});

Run a full build before and after, and compare wall-clock time. If your CI logs build duration (most do), this is a five-minute experiment with a clear answer either way.

Context: Astro under Cloudflare

Worth noting for anyone who hasn’t been tracking it: Astro is no longer an independent company. Cloudflare acquired The Astro Technology Company earlier this year, and the team continues shipping Astro full-time as part of Cloudflare’s web platform push. Sätteri being tested against Cloudflare’s own docs site in this release isn’t a coincidence: it’s the acquisition paying off in the form of a shared testbed and, presumably, shared incentive to make markdown-heavy sites build faster on Cloudflare’s infrastructure. It’s also a natural follow-on from the edge computing and CSP work Astro previewed during the 6.0 beta, where Cloudflare integration was already the headline story.

The practical takeaway

If your Astro project has a plugin-light markdown pipeline and you care about build time, especially in CI where every minute is billed compute, switching to Sätteri today is close to a free win: one config line, no content changes, and a documented double-digit-second-to-minute-plus improvement on comparable sites. If you’ve built a markdown pipeline with several custom plugins doing real transformation work, stay on unified() for now and revisit once Sätteri’s plugin story matures. Nothing forces the decision before you’re ready.