Eigener Server statt Baukasten-Abo
Eine Yogalehrerin wollte ihre Website selbst pflegen können, zu festen Kosten und ohne an einen Anbieter gebunden zu sein. Astro und Strapi auf einem eigenen Server in Deutschland, entworfen und umgesetzt in zwölf Arbeitstagen.
Ausgangslage
Eine selbstständige Yogalehrerin, eine bestehende Website und drei Wünsche, die sich gegenseitig im Weg stehen.
Erstens: Inhalte selbst ändern können. Kurszeiten, Texte, Bilder, ohne dafür jemanden fragen zu müssen.
Zweitens: feste Kosten. Jeden Monat derselbe Betrag, unabhängig davon, wie gut die Seite läuft.
Drittens: keine Abhängigkeit von einem Anbieter, der später die Preise oder die Bedingungen ändert.
Der dritte Punkt streicht die naheliegenden Antworten. Ein Website-Baukasten erfüllt eins und zwei und verletzt drei. Ein Cloud-CMS rechnet nach Nutzern oder Zugriffen ab und stellt damit ausgerechnet das Wachstum in Rechnung, das man sich eigentlich wünscht.
Lösung
Astro für die Website, Strapi als CMS, beides in einem Repository. Das Ganze läuft auf einem kleinen eigenen Server in Deutschland: nginx, Postgres, das CMS als Dienst, die fertige Website als Dateien daneben.
Inhalte fließen in eine Richtung. Besucher:innen erreichen nie das CMS, sondern immer nur fertige Dateien.
Vier Entscheidungen tragen das Projekt.
Der Server hat eine feste Miete. Damit stehen die Betriebskosten fest, egal ob die Seite 200 oder 20.000 Besucher:innen im Monat hat. Bessere Sichtbarkeit erzeugt keine höhere Rechnung. Nebenbei liegen alle Daten bei einem Hoster in Deutschland, was Impressum und Datenschutzerklärung deutlich vereinfacht: keine Drittlandübermittlung, kein Flickenteppich aus Dienstleistern.
Seiten entstehen aus Blöcken, nicht aus Vorlagen. Sechzehn Blocktypen, die auf neun geteilten Komponenten aufsetzen. Eine neue Seite heißt: Blöcke wählen, anordnen, veröffentlichen. Kein Ticket, keine Zeile Code. Die Micro-Site für Yogalehrer:innen mit Website-Audit und Ratgeber ist genau so entstanden. Nach dem Veröffentlichen erzeugt sich die Website selbst neu und ist in unter einer Minute online.
Zwischen Website und CMS liegt eine Grenze. Die Website kennt kein Strapi. Sie kennt ein eigenes Datenmodell, und alles CMS-Spezifische steckt hinter einer einzigen Übersetzungsschicht. Das klingt nach Vorsorge für den großen Anbieterwechsel, zahlt sich aber im Kleinen aus: Als wiederverwendbare Inhaltsblöcke dazukamen, musste dafür keine einzige Seite angefasst werden.
Frontend und CMS liegen in einem Repository. Die Entwicklung lief KI-gestützt, und genau das bestimmt den Zuschnitt: Ein Assistent kann nur über das urteilen, was er gleichzeitig sieht. Liegen Website und CMS in getrennten Repositories, sieht er immer nur eine Hälfte und rät die andere — hier das Schema, dort das Datenmodell, und niemand prüft, ob beide zusammenpassen. In einem Repository liegt der ganze Zusammenhang offen: CMS-Schema, Domain-Modell, Darstellung. Eine neue Inhaltsart berührt sechs Stellen und bleibt trotzdem ein einziger Pull Request, der als Ganzes gebaut und geprüft wird. Getrennt wären es zwei, mit einer Reihenfolge-Abhängigkeit dazwischen. Und wird eine der sechs Stellen vergessen, bricht der Build: Konsistenz hängt nicht an Sorgfalt, sondern am Compiler.
Die Inhalte der alten Website liegen strukturiert im Repository und füllen das CMS beim ersten Start. Das hatte zwei Effekte. Die neue Struktur wurde von Anfang an gegen echte Texte geprüft statt gegen Blindtext, denn Blindtext verdeckt genau die Stellen, an denen eine Struktur zu starr ist. Und ein neuer Server lässt sich ohne Datenbank-Umzug aufsetzen. Sobald Julia anfängt zu schreiben, hält sich dieser Startzustand vollständig heraus: Struktur kommt aus dem Code, Inhalt aus dem CMS.
Ergebnis
Nach zwölf Arbeitstagen stand die Seite: fünfzehn Seiten, alle Inhalte der Vorgängerversion übernommen, keiner ging verloren.
Julia pflegt sie seitdem selbst, in einer Oberfläche, die sie ohne Schulung bedienen kann. Die laufenden Kosten sind eine Serverrechnung. Keine Lizenz, kein Nutzerlimit.
Ausgeliefert werden reine Dateien. Das ist schnell, bietet kaum Angriffsfläche und hat einen angenehmen Nebeneffekt: Die Website bleibt online, auch wenn das CMS gerade neu startet. Besucher:innen merken davon nichts. Sollte später etwas zur Laufzeit gerendert werden müssen, ist das ein Konfigurationswechsel und keine Neuentwicklung.
Ein Deployment ist ein Push. Jeder Stand landet in einem eigenen Verzeichnis, erst danach wird umgeschaltet, niemand sieht eine halb kopierte Seite. Ein fehlgeschlagener Build veröffentlicht nichts, die letzte funktionierende Version bleibt stehen. Zurück auf einen älteren Stand ist ein Befehl.
Was am Ende zählt: Das Projekt hängt an keiner Person. Die Redaktion braucht keine Entwicklung, der Betrieb braucht keine Handarbeit, und wer den Code in zwei Jahren übernimmt, findet ihn dokumentiert und reproduzierbar vor.