Astro 7.0.0-beta.4 Makes Sätteri the Default Markdown Processor, Promotes Advanced Routing, Custom Logger, and Queued Rendering to Stable

Astro 7.0.0-beta.4 shipped on June 15, 2026, the fourth beta on the 7.0 line and the first one where the previously opt-in Sätteri Rust-based Markdown pipeline is the default. The release also lands on top of two prior betas (7.0.0-beta.3 on June 9 and 7.0.0-beta.2 earlier in June) that did most of the work to stabilize advanced routing, the custom logger, and the new streaming rendering engine, plus two alphas (7.0.0-alpha.2 and 7.0.0-alpha.0) that brought the Vite 8 upgrade and the astro dev --background mode for AI coding agents. The 7.0 line follows the Astro 6 launch in March and the Astro 6.4 Sätteri opt-in; the headline 7.0 story is that almost every experimental feature that 6.x shipped behind a flag has graduated, the default Markdown processor is now Rust, and a handful of long-deprecated APIs are finally deleted.

Sätteri becomes the default Markdown processor

The headline of 7.0.0-beta.4 is PR #16966, which switches the default .md processor from the legacy unified/remark/rehype pipeline to Sätteri, the native Rust Markdown processor that Astro 6.4 shipped as an opt-in. The motivation is build performance: the Astro 6.4 launch post measured roughly 50 to 80 percent build-time wins on content-heavy sites, and the team has been treating Sätteri as the future of Astro Markdown since the Rust markdown optimizer landed. Beta.4 makes that future the default for every new and upgraded Astro project.

The change is mechanical for projects that do not touch markdown.remarkPlugins or markdown.rehypePlugins. The deprecation warnings on those config keys, which Astro 6.4 introduced, are now triggered by default; the keys still work as long as @astrojs/markdown-remark is installed and markdown.processor is set to unified():

// astro.config.mjs
import { defineConfig } from 'astro/config';
import { unified } from '@astrojs/markdown-remark';

export default defineConfig({
  markdown: {
    processor: unified(),
  },
});

If the project only used Markdown through the defaults (no remark/rehype plugins, no GFM, no syntax highlighting via unified), the upgrade is a no-op. Sätteri is API-compatible with the standard Markdown feature set that Astro's .md files use out of the box, and Astro 6.4 already added support for syntax highlighting via Shiki and GFM tables in Sätteri. The main migration cost is for projects that pulled in remark-mermaid, rehype-slug, or other custom plugins; those need to be ported to Sätteri's extension API or stay on the legacy pipeline.

The other practical effect is bundle size: @astrojs/markdown-remark and its transitive unified ecosystem are no longer installed by default, which means smaller node_modules and a faster cold install for projects that do not need them. The deprecation warning is now a hard requirement: if a config sets markdown.remarkPlugins or markdown.rehypePlugins, Astro 7.0 will refuse to start without @astrojs/markdown-remark as a direct dependency.

Advanced routing is stable, fetchFile is a top-level option

The biggest feature that 7.0 promotes from experimental is advanced routing, introduced behind experimental.advancedRouting in Astro 6.3. The feature gives full control over how requests flow through an Astro application, with first-class support for non-Astro routers like Hono. The 7.0 promotion makes it the default behavior, drops the experimental flag, and moves the entrypoint configuration to a new top-level fetchFile option.

The default entrypoint is now src/fetch.ts instead of src/app.ts. Projects that do not customize the entrypoint do not need to do anything; the new file is auto-created on first run. Projects that wrote a custom src/app.ts and relied on the experimental flag have two options:

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

export default defineConfig({
  fetchFile: 'app.ts', // keep the old entrypoint path
});

Or, if the project is starting fresh on 7.0, rename the entrypoint to src/fetch.ts and drop the experimental.advancedRouting flag entirely. fetchFile: null disables the entrypoint for projects that want to keep src/fetch.ts as their own file.

The promotion also stabilizes the astro/hono integration. getFetchState() is now a public API on astro/hono, retrievable from a Hono context object so third-party packages can build Hono middleware that interacts with Astro's per-request state. The integration gives astro/hono the same extensibility that astro/fetch has had since 6.0.

Custom logger and the new rendering engine are stable

Two other 6.x experimental features graduate in 7.0. PR #16745 stabilizes the custom logger, which lets projects replace Astro's default console output with structured JSON, or a custom logger entrypoint that talks to a log aggregation service. The new built-in handlers are logHandlers.json(), logHandlers.node(), and logHandlers.console():

import { defineConfig, logHandlers } from 'astro/config';

export default defineConfig({
  logger: logHandlers.json({
    pretty: true,
    level: 'warn',
  }),
});

context.logger is now always available in API routes and middleware, even without a custom logger configured, which removes a long-standing footgun where a project that did not opt in would silently get a default logger that could not be customized.

PR #16981 removes experimental.queuedRendering entirely, since the streaming rendering engine that replaced it is now stable. The old queue-based engine is gone; the new engine streams components as they are encountered, drops node polling (which did not yield concrete savings), and shrinks the content cache to a tag-name cache. The migration is to remove the experimental.queuedRendering: {} flag from the config; if a project had it set, the key no longer exists and Astro 7.0 will warn about it before falling back to the default.

Background dev server for AI coding agents

The 7.0.0-alpha.2 release added a feature that has been quietly popular with the AI-coding-agent ecosystem: background dev server management. When an AI coding agent is detected, astro dev now automatically starts the dev server as a detached background process, writing a lock file (.astro/dev.json) with the server's URL, port, and PID. The new subcommands are astro dev --background (start in the background), astro dev stop (kill it), astro dev status (check URL, PID, uptime), and astro dev logs (with --follow / -f to stream new output).

The motivation is straightforward: AI coding agents (Claude Code, Codex CLI, Cursor) run in terminals where a foreground dev server blocks the agent's main loop. The background mode keeps the server alive across the agent's tool calls and writes structured output to a log file the agent can tail. The opt-out is ASTRO_DEV_BACKGROUND=0. The feature is now the default in agent contexts, which is most of the AI-coding-agent CLI landscape by mid-2026.

The lock file is also the wedge for a broader capability the team is building toward: agents can read .astro/dev.json to know which dev server is associated with a project, restart it on demand, and clean it up at the end of a session. The same lock pattern is the foundation for the astro dev lifecycle hooks several integrators have been asking for since 6.4.

What is removed in Astro 7.0

The 7.0 line is also a clean-up release. PR #17010 removes the astro db, astro login, astro logout, astro link, and astro init CLI commands. @astrojs/db is deprecated; the team's recommendation is to use a database client (Drizzle, Kysely, etc.) directly. astro init had been mostly replaced by npm create astro@latest. The other three were products Astro is no longer investing in.

The deprecated astro:transitions and astro:transitions/client helpers (TRANSITION_BEFORE_PREPARATION, TRANSITION_AFTER_PREPARATION, TRANSITION_BEFORE_SWAP, TRANSITION_AFTER_SWAP, TRANSITION_PAGE_LOAD, the two isTransition*Event() type guards, and createAnimationScope()) are also removed. The replacement is to use the lifecycle event names directly (event.type === 'astro:before-preparation', 'astro:after-swap', etc.). The internal state.provide(), state.resolve(), state.finalizeAll(), and App.Providers extension points on the advanced routing API are also removed; the public replacement is locals for per-request state.

The 7.0 line is also the first to officially support Vite 8; the 7.0.0-alpha.1 patch explicitly removes the warning that Astro does not support Vite v8. The 7.0 betas are built and tested against the Vite 8 stable branch, which means the Vite 8.1 beta features (direct .wasm imports, build.chunkImportMap, the server.hmr → server.ws rename) are available to Astro 7 projects as soon as the user upgrades Vite to 8.1.

Who is affected

The migration cost for the average Astro project is low: most projects will see a faster Markdown pipeline on upgrade, and the new defaults just work. The riskier migrations are the ones that touched experimental.advancedRouting (drop the flag, decide whether to rename to src/fetch.ts or set fetchFile), the ones that used astro:transitions event constants (replace with the string event names), and the ones that depend on the removed CLI commands (astro db, astro login, astro logout, astro link, astro init).

The 7.0 stable cut is expected once the current beta feedback stabilizes, with the deprecation warnings on markdown.remarkPlugins, markdown.rehypePlugins, and markdown.remarkRehype continuing to be loud for another release cycle before they become hard errors. Until then, 7.0.0-beta.4 is the right version to validate against, and the right time to file any remaining complaints about the Sätteri default or the new src/fetch.ts entrypoint convention.