Astro 7.0.0-beta.4 wurde am 15. Juni 2026 veröffentlicht, die vierte Beta der 7.0-Linie und die erste, in der die bisher optionale Rust-basierte Markdown-Pipeline Sätteri zum Standard wird. Das Release baut auf zwei vorherigen Betas auf (7.0.0-beta.3 am 9. Juni und 7.0.0-beta.2 Anfang Juni), die den Großteil der Arbeit zur Stabilisierung von erweitertem Routing, benutzerdefiniertem Logger und der neuen Streaming-Rendering-Engine geleistet haben, sowie auf zwei Alphas (7.0.0-alpha.2 und 7.0.0-alpha.0), die das Vite-8-Upgrade und den astro dev --background-Modus für KI-Code-Agenten brachten. Die 7.0-Linie folgt auf den Astro-6-Launch im März und auf Astro 6.4 mit Sätteri als Opt-in; der rote Faden von 7.0 ist, dass fast alle experimentellen Funktionen, die 6.x hinter einem Flag ausgeliefert hat, nun graduieren, der Standard-Markdown-Prozessor nun in Rust läuft und eine Reihe lange veralteter APIs endlich gelöscht werden.
Sätteri wird zum Standard-Markdown-Prozessor
Das Ereignis von 7.0.0-beta.4 ist PR #16966, die den Standard-.md-Prozessor von der Legacy-unified/remark/rehype-Pipeline auf Sätteri umstellt, den nativen Rust-Markdown-Prozessor, den Astro 6.4 als Opt-in ausgeliefert hat. Die Motivation ist Build-Performance: der Astro-6.4-Launch-Post maß Gewinne von etwa 50 bis 80 Prozent bei den Build-Zeiten inhaltslastiger Sites, und das Team behandelt Sätteri als die Zukunft von Astro-Markdown, seit der Rust-Markdown-Optimizer eingeführt wurde. Beta.4 macht diese Zukunft zum Standard für jedes neue und jedes aktualisierte Astro-Projekt.
Die Änderung ist mechanisch für Projekte, die markdown.remarkPlugins oder markdown.rehypePlugins nicht anfassen. Die in Astro 6.4 eingeführten Deprecation-Warnungen für diese Konfigurationsschlüssel werden nun standardmäßig ausgelöst; die Schlüssel funktionieren weiterhin, sofern @astrojs/markdown-remark installiert ist und markdown.processor auf unified() gesetzt ist:
// astro.config.mjs
import { defineConfig } from 'astro/config';
import { unified } from '@astrojs/markdown-remark';
export default defineConfig({
markdown: {
processor: unified(),
},
});
Wenn das Projekt Markdown nur über die Defaults verwendet (keine remark/rehype-Plugins, kein GFM, keine Syntaxhervorhebung über unified), ist das Upgrade ein No-op. Sätteri ist API-kompatibel mit dem Standardumfang der Markdown-Funktionen, den Astros .md-Dateien out of the box nutzen, und Astro 6.4 hat in Sätteri bereits Syntaxhervorhebung über Shiki und GFM-Tabellen unterstützt. Die wesentlichen Migrationskosten betreffen Projekte, die auf remark-mermaid, rehype-slug oder andere benutzerdefinierte Plugins gesetzt haben; diese müssen entweder auf Sätteris Erweiterungs-API portiert werden oder auf der Legacy-Pipeline bleiben.
Ein weiterer praktischer Effekt ist die Bundle-Größe: @astrojs/markdown-remark und sein transitive unified-Ökosystem werden nicht mehr standardmäßig installiert, was sich in einem kleineren node_modules und einem schnelleren Cold-Install für Projekte niederschlägt, die darauf verzichten können. Die Deprecation-Warnung wird zur harten Anforderung: setzt eine Konfiguration markdown.remarkPlugins oder markdown.rehypePlugins, weigert sich Astro 7.0 zu starten, sofern @astrojs/markdown-remark nicht als direkte Abhängigkeit vorhanden ist.
Erweitertes Routing wird stabil, fetchFile rückt auf die Top-Level-Ebene
Die größte Funktion, die 7.0 aus dem experimentellen Status befördert, ist das erweiterte Routing, eingeführt hinter experimental.advancedRouting in Astro 6.3. Die Funktion gibt die volle Kontrolle darüber, wie Anfragen durch eine Astro-Anwendung fließen, mit erstklassiger Unterstützung für Nicht-Astro-Router wie Hono. Die 7.0-Beförderung macht es zum Standardverhalten, entfernt das experimentelle Flag und verschiebt die Entry-Point-Konfiguration auf eine neue Top-Level-Option fetchFile.
Der Standard-Entry-Point ist nun src/fetch.ts statt src/app.ts. Projekte, die den Entry-Point nicht anpassen, müssen nichts tun; die neue Datei wird beim ersten Lauf automatisch erzeugt. Projekte, die ein benutzerdefiniertes src/app.ts geschrieben haben und sich auf das experimentelle Flag verlassen, haben zwei Optionen:
// astro.config.mjs
import { defineConfig } from 'astro/config';
export default defineConfig({
fetchFile: 'app.ts', // alten Entry-Point-Pfad beibehalten
});
Oder, wenn das Projekt frisch auf 7.0 startet, benennt man den Entry-Point in src/fetch.ts um und entfernt das experimental.advancedRouting-Flag vollständig. fetchFile: null deaktiviert den Entry-Point für Projekte, die src/fetch.ts als eigene Datei behalten wollen.
Die Beförderung stabilisiert auch die astro/hono-Integration. getFetchState() ist nun eine öffentliche API von astro/hono, abrufbar aus einem Hono-Kontextobjekt, sodass Drittanbieter-Pakete Hono-Middleware bauen können, die mit Astros Per-Request-State interagiert. Die Integration gibt astro/hono die gleiche Erweiterbarkeit, die astro/fetch seit 6.0 hat.
Benutzerdefinierter Logger und neue Streaming-Rendering-Engine werden stabil
Zwei weitere experimentelle Funktionen der 6.x werden in 7.0 befördert. PR #16745 stabilisiert den benutzerdefinierten Logger, der es Projekten erlaubt, Astros Standard-Konsolenausgabe durch strukturiertes JSON oder einen benutzerdefinierten Logger-Entry-Point zu ersetzen, der mit einem Log-Aggregationsdienst spricht. Die eingebauten Handler sind logHandlers.json(), logHandlers.node() und logHandlers.console():
import { defineConfig, logHandlers } from 'astro/config';
export default defineConfig({
logger: logHandlers.json({
pretty: true,
level: 'warn',
}),
});
context.logger ist nun in API-Routen und Middleware immer verfügbar, auch ohne konfigurierten benutzerdefinierten Logger, was eine langjährige Stolperfalle beseitigt: ein Projekt, das sich nicht aktiv entschied, bekam stillschweigend einen nicht anpassbaren Default-Logger.
PR #16981 entfernt experimental.queuedRendering vollständig, da die Streaming-Rendering-Engine, die es abgelöst hat, nun stabil ist. Die alte Queue-basierte Engine verschwindet; die neue Engine streamt Komponenten, sobald sie angetroffen werden, verzichtet auf das Node-Polling (das keine konkreten Gewinne brachte) und schrumpft den Content-Cache auf einen Tag-Namens-Cache. Die Migration besteht darin, das experimental.queuedRendering: {}-Flag aus der Konfiguration zu entfernen; hatte ein Projekt es gesetzt, existiert der Schlüssel nicht mehr und Astro 7.0 gibt eine Warnung aus, bevor es auf den Default zurückfällt.
Dev-Server im Hintergrund für KI-Code-Agenten
7.0.0-alpha.2 hat eine Funktion hinzugefügt, die im Ökosystem der KI-Code-Agenten still und leise populär geworden ist: die Verwaltung des Dev-Servers im Hintergrund. Wird ein KI-Code-Agent erkannt, startet astro dev den Dev-Server automatisch als detached Hintergrundprozess und schreibt eine Lock-Datei (.astro/dev.json) mit der Server-URL, dem Port und der PID. Die neuen Subkommandos sind astro dev --background (im Hintergrund starten), astro dev stop (beenden), astro dev status (URL, PID, Uptime prüfen) und astro dev logs (mit --follow / -f, um neue Ausgaben zu streamen).
Die Motivation ist einfach: KI-Code-Agenten (Claude Code, Codex CLI, Cursor) laufen in Terminals, in denen ein im Vordergrund laufender Dev-Server die Hauptschleife des Agenten blockiert. Der Hintergrundmodus hält den Server über die Tool-Aufrufe des Agenten hinweg am Leben und schreibt strukturierte Ausgaben in eine Log-Datei, die der Agent mitlesen kann. Der Opt-out ist ASTRO_DEV_BACKGROUND=0. Die Funktion ist nun in Agentenkontexten der Standard, was Mitte 2026 den Großteil der CLI-Landschaft der KI-Code-Agenten ausmacht.
Die Lock-Datei ist auch der Ansatzpunkt für eine breitere Fähigkeit, die das Team schrittweise aufbaut: Agenten können .astro/dev.json lesen, um zu wissen, welcher Dev-Server zu einem Projekt gehört, ihn bei Bedarf neu starten und am Ende einer Session aufräumen. Dasselbe Lock-Muster bildet die Grundlage für die Lifecycle-Hooks von astro dev, die mehrere Integratoren seit 6.4 nachfragen.
Was in Astro 7.0 entfernt wird
Die 7.0-Linie ist auch ein Cleanup-Release. PR #17010 entfernt die CLI-Befehle astro db, astro login, astro logout, astro link und astro init. @astrojs/db ist veraltet; die Empfehlung des Teams ist, direkt einen Datenbank-Client (Drizzle, Kysely usw.) zu verwenden. astro init war bereits weitgehend durch npm create astro@latest ersetzt worden. Die anderen drei sind Produkte, in die Astro nicht mehr investiert.
Die veralteten Helfer aus astro:transitions und astro:transitions/client (TRANSITION_BEFORE_PREPARATION, TRANSITION_AFTER_PREPARATION, TRANSITION_BEFORE_SWAP, TRANSITION_AFTER_SWAP, TRANSITION_PAGE_LOAD, die beiden isTransition*Event()-Type-Guards und createAnimationScope()) werden ebenfalls entfernt. Der Ersatz besteht darin, die Lifecycle-Event-Namen direkt zu nutzen (event.type === 'astro:before-preparation', 'astro:after-swap' usw.). Auch die internen Erweiterungspunkte state.provide(), state.resolve(), state.finalizeAll() und App.Providers der Advanced-Routing-API werden entfernt; der öffentliche Ersatz ist locals für den Per-Request-State.
Die 7.0-Linie ist zudem die erste, die Vite 8 offiziell unterstützt; der Patch 7.0.0-alpha.1 entfernt ausdrücklich die Warnung, dass Astro Vite v8 nicht unterstützt. Die 7.0-Betas werden gegen den stabilen Vite-8-Branch gebaut und getestet, was bedeutet, dass die Funktionen der Vite-8.1-Beta (direkte .wasm-Imports, build.chunkImportMap, Umbenennung server.hmr → server.ws) Astro-7-Projekten zur Verfügung stehen, sobald der Anwender Vite auf 8.1 aktualisiert.
Wer ist betroffen
Die Migrationskosten für das durchschnittliche Astro-Projekt sind gering: die meisten werden beim Upgrade eine schnellere Markdown-Pipeline sehen, und die neuen Defaults funktionieren einfach. Die riskanteren Migrationen sind diejenigen, die experimental.advancedRouting angefasst haben (Flag entfernen, entscheiden, ob man nach src/fetch.ts umbenennt oder fetchFile setzt), diejenigen, die astro:transitions-Event-Konstanten verwendet haben (durch die Event-Namen als Strings ersetzen) und diejenigen, die von den entfernten CLI-Befehlen abhängen (astro db, astro login, astro logout, astro link, astro init).
Der stabile 7.0-Cut wird erwartet, sobald sich das aktuelle Beta-Feedback stabilisiert, wobei die Deprecation-Warnungen auf markdown.remarkPlugins, markdown.rehypePlugins und markdown.remarkRehype für einen weiteren Release-Zyklus laut bleiben, bevor sie zu harten Fehlern werden. Bis dahin ist 7.0.0-beta.4 die richtige Version, gegen die man validiert, und der richtige Zeitpunkt, um verbleibende Beschwerden über den Sätteri-Default oder die neue src/fetch.ts-Entry-Point-Konvention einzureichen.
