Astro Support und Wartung für Websites, die im Betrieb sind.

Astro folgt Semantic Versioning und veröffentlicht Major-Versionen in kurzen Abständen: Astro 6.0 wurde im März 2026 stabil, Astro 7.0 im Juni 2026, Astro 7.2 im August 2026. Security-Fixes gibt es für genau eine vorherige Major-Version. Praktisch heißt das: kleinere Updates laufend, ein geplantes Major-Upgrade pro Zyklus – damit Sie nie zwei Majors zurückliegen und aus dem Sicherheitsfenster fallen.

Das hängt am Umfang. Eine statische Marketing-Site mit gelegentlichen Inhalten liegt deutlich unter einer Seite mit Server-Rendering, CMS-Anbindung und laufender Weiterentwicklung. Wir kalkulieren erst nach der Bestandsaufnahme und nennen den Rahmen schriftlich, aufgeschlüsselt nach Grundpflege und Weiterentwicklung. Eine Einordnung der Projektkosten finden Sie unter Astro-Kosten.

Ja – nach einem Audit. Wir prüfen Repository, Astro-Version, Adapter, Content Collections, Integrationen und Build und geben einen schriftlichen Befund ab. Wenn wir zu dem Schluss kommen, dass der Code nicht tragfähig ist, sagen wir ab oder empfehlen einen Neubau. Wir übernehmen keine Verantwortung für Code, den wir nicht verantworten können – das wäre für beide Seiten ein schlechtes Geschäft.

Sie behalten alles. Repository, Hosting-Account, Domain, CMS und Dokumentation laufen von Anfang an auf Ihren Namen, und wir arbeiten mit Zugängen, die Sie jederzeit entziehen können. Zum Abschluss gibt es eine Übergabe mit aktuellem Versionsstand, offenen Punkten und dem Deployment-Ablauf. Astro steht unter MIT-Lizenz; am Framework hängt keine Abhängigkeit zu uns.

Ein Major-Sprung kann Breaking Changes enthalten – genau dafür ist Semantic Versioning da. Deshalb passiert ein Upgrade nie direkt auf Produktion: erst in einem Branch, entlang der dokumentierten Upgrade-Hinweise, mit Build- und Linkprüfung und einer Vorschau, die Sie selbst durchklicken. Erst danach geht es live. Das ist der Grund, warum Wartung geplant und nicht reaktiv sein sollte.

Ja, das ist der Normalfall. Inhalte liegen entweder als Content Collections im Repository oder in einem angebundenen Headless CMS – in beiden Fällen bearbeitet Ihr Team sie ohne uns. Wir kommen ins Spiel, wenn das Modell erweitert werden muss: neue Felder, neue Collections, neue Seitentypen. Wie das im Alltag aussieht, zeigt die Seite Website per Chat pflegen.

Ja. Ein Retainer ist bei uns keine Bedingung. Manche Projekte brauchen nur ein Update-Fenster im Jahr, und dann beauftragen Sie genau das. Wir sagen offen, wenn ein monatlicher Vertrag für Ihre Seite keinen Sinn ergibt – eine kleine statische Website ist selten ein Retainer-Fall. Umgekehrt gilt: Sobald Server-Rendering, CMS und Integrationen im Spiel sind, wird punktuelle Wartung schnell teurer als geplante.

An Werktagen am selben Tag, in aller Regel innerhalb weniger Stunden: Jemand sieht sich das an und sagt Ihnen, was los ist. Wie schnell es behoben ist, hängt an der Ursache – ein fehlgeschlagener Deploy ist in Minuten zurückgerollt, ein Ausfall beim Hosting-Anbieter liegt nicht in unserer Hand. Was wir nicht anbieten: Rufbereitschaft rund um die Uhr. Brauchen Sie echte 24/7-Abdeckung, gehört die in den Hosting-Vertrag – und wir sagen das vor der Unterschrift.

Enthalten sind: Updates von Astro, Build-Unterbau, UI-Integrationen und CMS-SDKs, die Pflege von Adapter, Pipeline und Umgebungsvariablen, kleine Korrekturen, die Reaktion auf Monitoring-Meldungen und ein schriftlicher Status. Nicht enthalten und deshalb eine eigene Beauftragung: neue Seitentypen, Design-Arbeit, redaktionelle Inhalte, Migrationen, Kampagnenstrecken sowie eine Barrierefreiheits-Prüfung. In welche der beiden Kategorien eine Anfrage fällt, sagen wir vorher – nicht auf der Rechnung.

In dieser Reihenfolge: Rollback auf den letzten funktionierenden Build, dann Ursachensuche im Branch, dann ein neuer Deploy mit Prüfung. Genau deshalb laufen Änderungen über Pull Requests mit Vorschau-Umgebung statt direkt auf Produktion. Sie erreichen dabei eine benannte Person, die Ihr Projekt kennt, keine Warteschlange. Die ehrliche Einschränkung: Ein Rollback ist nur so gut wie die Pipeline. Bei übernommenen Projekten ohne reproduzierbaren Build ist das der erste Punkt der Stabilisierung.

Wir sind ein kleines Team, das ist ein echtes Risiko, und wir behandeln es entsprechend. Alles läuft in Ihren Accounts: Repository, Hosting, Domain, CMS. Im Repository liegt eine Dokumentation zu Build, Deployment, Umgebungsvariablen und Inhaltsmodell, und der Build ist reproduzierbar. Astro steht unter MIT-Lizenz; kein Baustein ist an uns gebunden. Jedes Team, das mit JavaScript und Git arbeitet, kann übernehmen. Unangenehm bleibt ein Wechsel trotzdem – aber er ist keine Neuentwicklung.

Unser Standardvorschlag ist eine monatliche Abrechnung mit vier Wochen Kündigungsfrist zum Monatsende und ohne Mindestlaufzeit. Wenn Ihr Einkauf eine feste Laufzeit, andere Fristen oder zugesagte Reaktions- und Wiederherstellungszeiten braucht, verhandeln wir das schriftlich – dann ist es verbindlich. Kurz halten wir die Frist bewusst: Eine Wartungsvereinbarung sollte sich jeden Monat neu rechtfertigen. Wer bleibt, weil Kündigen zu teuer wäre, ist kein zufriedener Kunde.

Wir – für das, was wir geändert haben. Was nach einem von uns ausgelieferten Update nicht mehr so funktioniert wie vereinbart, stellen wir im Rahmen der gesetzlichen Gewährleistung ohne neue Rechnung wieder her. Davon zu trennen sind Störungen aus einem Fremdsystem – Hosting-Anbieter, CMS, Zahlungsdienst – und Änderungswünsche, die kein Mangel sind. In welche Kategorie eine Meldung fällt, sagen wir, bevor wir anfangen. Weitergehende Haftungsregelungen gehören in die Vereinbarung, nicht auf eine Website.

Dass eine vorgerenderte Astro-Seite im Auslieferungspfad keine Datenbank, kein Admin-Login und kein Plugin-Ökosystem hat – der übliche Weg über eine verwundbare Erweiterung existiert dort nicht. Was bleibt und deshalb gepflegt wird: npm-Abhängigkeiten, Repository- und Pipeline-Rechte, Formular- und API-Endpunkte, ein Headless CMS als eigenes System mit eigener Anmeldung sowie Domain- und Hosting-Konten. Wir arbeiten mit Zwei-Faktor-Pflicht, minimalen Rechten und Zugängen in Ihren Accounts, die Sie jederzeit entziehen können. Wo Geheimnisse liegen, ist dokumentiert.

Astro selbst verarbeitet keine personenbezogenen Daten – die Frage entscheidet sich an Hosting, Formularen, Analytics und CMS. Ein statischer Build lässt sich bei einem Anbieter in Deutschland oder der EU betreiben; Schriften binden wir selbst ein statt über fremde Server, und für Analytics gibt es Varianten ohne Cookies. Jeden eingesetzten Dienstleister benennen wir, damit Ihr Datenschutzbeauftragter die Auftragsverarbeitungsverträge schließen kann, und Änderungen an dieser Liste melden wir. Rechtsberatung leisten wir nicht. Details unter DSGVO-konforme Website.

Ja, und wir sagen es lieber, als es zu verschweigen. KI-gestützte Werkzeuge beschleunigen Routinearbeit wie Abhängigkeits-Updates, Migrationsschritte und Testfälle; verantwortlich bleibt ein Mensch. Jede Änderung läuft durch Review, Typprüfung und Build in der Continuous Integration, bevor sie ausgeliefert wird. Zugangsdaten, personenbezogene Kundendaten und vertrauliche Dokumente gehören nicht in solche Werkzeuge – das ist bei uns Regel, nicht Ermessensfrage. Schränkt Ihre Richtlinie den Einsatz ein oder schließt ihn aus, halten wir uns daran und schreiben es in den Vertrag.

Ja, darauf ist das Setup ausgelegt. Sie bekommen das Repository mit vollständiger Historie, dokumentierte Build- und Deployment-Schritte, eine Übersicht der Umgebungsvariablen und eine Übergabe mit offenen Punkten. Zur Sorge dahinter: Astro-Komponenten sind HTML, CSS und TypeScript, interaktive Inseln entstehen in React, Preact, Svelte, Vue, SolidJS oder Alpine.js. Sie stellen also aus dem allgemeinen JavaScript-Markt ein, nicht aus einem Astro-Markt. Weniger Lebensläufe mit „Astro“ darin gibt es trotzdem – Einarbeitungszeit planen Sie ein.

Weil wir das lieber sagen, als eine zu erfinden: Ein öffentlich zeigbares Astro-Kundenprojekt haben wir bislang nicht. Was wir haben, ist eine gebaute und betreute Webflow-Referenz, eigene Produkte im laufenden Betrieb und Jahre an Software-Entwicklung mit Repository, Continuous Integration und Deployment. Betrieb ist der größere Teil dieser Arbeit, das Framework der kleinere. Prüfen können Sie uns günstig: Das Audit ist ein abgeschlossener Auftrag, kein Vertrag – und der Befund bleibt bei Ihnen, auch wenn Sie danach jemand anderen beauftragen.

Ja. Astro ist quelloffene Software unter der MIT-Lizenz; für das Framework selbst fällt keine Lizenzgebühr an. Kosten entstehen bei Umsetzung, Hosting, Betrieb und – falls Sie eins einsetzen – beim Headless CMS. Die Treiber stehen einzeln unter Astro-Kosten.

Astro folgt Semantic Versioning. Extended Maintenance mit reinen Security-Fixes gibt es laut Upgrade-Dokumentation für genau eine vorherige Major-Version. Wer zwei Majors zurückliegt, betreibt eine Website ohne Sicherheitspatches – deshalb ist ein geplantes Upgrade-Fenster der billigste Teil jeder Wartung.

Nicht zwingend. Standardmäßig wird die gesamte Website vorgerendert und als statisches HTML ausgeliefert – das läuft auf jedem CDN oder statischen Hosting. Erst wenn einzelne Routen zur Laufzeit rendern sollen, kommt ein Adapter für die Ziellaufzeit dazu, etwa für Node, Vercel oder Cloudflare. Mehr dazu unter Astro-Hosting.

Ja. Es gibt offizielle Integrationen für React, Preact, Svelte, Vue, SolidJS und Alpine.js, und mehrere davon dürfen auf derselben Seite vorkommen – allerdings nur innerhalb einer .astro-Datei. Für die Wartung heißt das: Jede dieser Integrationen hat einen eigenen Release-Zyklus und wird im Update-Fenster mitgepflegt.