Astro launches Sätteri, a Rust Markdown processor promising builds up to 60% faster

The Astro team introduced Sätteri, a high-performance Markdown and MDX processor written in Rust that is now at the heart of the recently launched Astro 7.0. According to the team, it delivers builds up to 60% faster by replacing the JavaScript pipeline based on remark, rehype, and a long tail of dependencies.

For those building content sites with Astro in Brazil (technical blogs, documentation, editorial portals), the change has an immediate practical effect: build time drops without needing to switch frameworks, and most projects require no code changes at all.

What Sätteri Is and How It Works

Sätteri places flexible JavaScript plugins on top of a fast Markdown and MDX engine written in Rust. Under the hood, it uses pulldown-cmark for CommonMark parsing and Oxc to interpret MDX expressions.

It ships as platform-specific native binaries, with a WASM fallback (the same approach Astro takes for its new Rust compiler). You can even test it directly in the browser via WebAssembly.

Interestingly, the project lives outside the Astro organization: it is maintained separately by core contributor Erika, under the Bruits collective, but it has become a central dependency of the framework.

Where the Performance Gain Comes From

Much of the speedup comes from taking parsing out of JavaScript. The previous pipeline, based on unified with remark and rehype, ran plugin after plugin over the entire syntax tree, which took its toll on large builds.

The numbers cited by the team are concrete: migrating Astro's own documentation and Cloudflare's to Sätteri cut more than a minute off each build, and overall Astro 7 builds improved between 15% and 61%.

Sätteri debuted as the optional @astrojs/markdown-satteri package in Astro 6.4 and has now been promoted to the default in Astro 7.

Features That No Longer Need a Plugin

Speed isn't the only change. Sätteri implements natively several features that previously required separate plugins:

• GitHub Flavored Markdown
• Smart punctuation
• Container directives
• Math
• Frontmatter
• Superscript and subscript
• Wikilinks

Optional features are enabled through the processor's configuration. In practice, this means fewer dependencies to manage (Erika mentions a pipeline that is roughly 100 dependencies leaner).

The Migration Catch: remark and rehype

The main caveat when migrating is that Sätteri does not run remark or rehype plugins. The Astro v7 upgrade guide advises:

• Projects without plugins don't need any changes.
• Projects that depend on plugins can port them to Sätteri's MDAST or HAST plugins, or stay on unified by installing @astrojs/markdown-remark.

The upgrade is done with:

npx @astrojs/upgrade

The decision to move away from the unified ecosystem drew reaction. On Hacker News, a developer complained: "Switching from the widely-supported unified/rehype to a proprietary tool that's incompatible with rehype just for a build-time improvement is pretty annoying. It's good that they added a way to keep using rehype, but I'm not sure it will last".

Erika replied that there is no intention to remove support for the unified ecosystem: "We made the Markdown processing pipeline pluggable on purpose, so both could exist. The vast majority of our users don't use any unified plugins, so a faster pipeline (and about 100 dependencies lighter) felt like a better default".

How It Compares to Other Options

Asked about the difference from a standard library like marked, Erika pointed to her public benchmarks and summarized: marked is quite lightweight, but a bit slower than Sätteri and markdown-it (and its forks). The differentiator she highlights is that Sätteri reuses the same AST format as the unified ecosystem, which tends to make extensibility easier.

Sätteri also isn't alone in the race for native Markdown. Bun.markdown, written in Zig, reports comparable gains, but has no plugin system, which leaves the reuse of unified's AST as Sätteri's distinguishing advantage.

The project is open source and is available via npm and crates.io.

What Remains Open

The question raised in the community is whether the bridge to the unified ecosystem will remain alive in the long run, now that it's no longer the default path. For Brazilian developers who already maintain Astro sites with MDX, the practical recommendation is straightforward: if you don't use remark/rehype plugins, run npx @astrojs/upgrade and reap the time savings; if you do, consider porting the plugins or pinning @astrojs/markdown-remark before updating.