Astro 6.4 goes after two things content teams complain about: slow Markdown builds and the glue code around Cloudflare deployment. It opens the Markdown pipeline so you can replace it wholesale, ships a Rust-based replacement called Sätteri, and adds routing helpers to the Cloudflare adapter. None of it changes how you author content. For where 6.4 sits in the release line, see the Astro 6 feature overview.
A pluggable Markdown pipeline
Until now the Markdown layer was effectively fixed: you could add plugins to it, but not replace it. The new markdown.processor option flips that. Point it at a processor, and that processor owns turning Markdown into HTML.
The default stays put. Leave markdown.processor unset and you keep the unified-based pipeline most projects already run, with the same remark and rehype plugins. Setting it is the opt-in for anyone who wants a different engine under the same authoring surface. The rest of the Astro 6 release coverage tracks the other versions.
Sätteri: Markdown in Rust
Sätteri is the first processor built for the new API, shipped as @astrojs/markdown-satteri. Install it, set it as your markdown.processor, and the build runs the Rust path instead of the JavaScript one. The payoff is build time: on content-heavy sites Markdown parsing is a real chunk of every build, and a compiled pipeline cuts it down. With hundreds or thousands of pages, this is the line item to watch.
The tradeoff: a Rust engine is not the unified ecosystem, so a remark or rehype plugin you depend on may have no equivalent. Sites on a deep plugin stack should diff the output before committing; sites with plain Markdown and a build clock that hurts are the clearest fit. Switch markdown.processor, run a build, compare the HTML.
Cloudflare routing helpers
The second change lands in @astrojs/cloudflare, the adapter that targets Cloudflare's runtime. Astro 6.4 adds advanced routing helpers through a cf() function, building on the advanced routing work in 6.3. It covers two jobs: injecting the SESSION KV binding, and serving static assets through the ASSETS binding.
Both were hand-wired before. A SESSION KV namespace had to be threaded through config into the runtime, and asset serving via the ASSETS binding meant writing the plumbing yourself. The cf() helper folds that into one call, so the KV binding and asset routing arrive configured rather than improvised. On an Astro app deploying to Cloudflare, that is less boilerplate between a fresh project and a working deploy.
Both threads point one way: 6.4 makes the slow and fiddly parts swappable. The Markdown engine is now a choice, and Sätteri is the first answer — expect more processors once the API settles. Run a large content site or deploy on Cloudflare, and this is the release to measure against your own build.