Astro Framework statt CMS: Der Relaunch von syfrt.de

Update, Oktober 2026: Gebaut und ausgeliefert wird die Seite inzwischen über Coolify auf meinem eigenen Hetzner-Server: Jeder Push ins eigene Git (Forgejo) löst einen neuen Build aus. Wie das aufgebaut ist, steht im Beitrag Self-Hosting mit Coolify, Forgejo & Astro. Am Prinzip unten ändert das nichts – es bleiben statische Dateien.

Selbstkritik als Ausgangspunkt

Im Januar habe ich beschrieben, wie diese Website entstand: Next.js 16, Directus als Headless CMS, ein selbstgebauter Page Builder mit M2A-Relationen, Draft Mode, On-Demand Revalidation, PM2 auf dem eigenen Server. Technisch hat das alles funktioniert – und es war eine schöne Referenz für moderne Web-Architektur.

Sechs Monate später habe ich es abgeschafft.

Nicht, weil etwas kaputt war. Sondern weil ich bei einem ehrlichen Blick auf die Seite eine Frage nicht gut beantworten konnte: Welches Problem löst dieser Stack – für diese Seite?

Die Rechnung, die nicht aufging

Meine Website hat rund ein Dutzend Seiten, ein paar Blogposts und Referenzen. Der Inhalt ändert sich ein paarmal im Monat, und es gibt genau einen Redakteur: mich. Dafür liefen:

• ein Node.js-Prozess (PM2), der jede Anfrage server-seitig renderte
• eine Directus-Instanz mit eigener Datenbank auf einer Subdomain
• ein Page-Builder-Datenmodell, dessen Pflege mehr Zeit kostete als das Schreiben der Inhalte selbst
• Updates für zwei Systeme, Monitoring für zwei Systeme, Backups für zwei Systeme

Das ist genau der Rat, den ich Kunden in Webprojekten gebe – nur umgekehrt: Die einfachste Lösung wählen, die das Ziel erreicht. Ein CMS lohnt sich, wenn mehrere Personen regelmäßig Inhalte pflegen. Für eine Ein-Personen-Firmenseite ist es Wartungslast ohne Nutzen.

Der neue Stack: weniger von allem

Die Seite ist jetzt ein statisches Astro-Projekt:

• Inhalte als Markdown im Git-Repository – versioniert, diffbar, ohne Datenbank
• Vanilla CSS mit Design-Tokens statt Framework – das komplette Design wohnt in einer Datei mit CSS-Variablen
• Schriften lokal via Fontsource statt Google-Fonts-CDN – gut für Datenschutz und Ladezeit
• Build → statische Dateien → nginx. Kein Node-Prozess, kein CMS, minimale Angriffsfläche, kaum etwas zu patchen

Deployen heißt jetzt: einmal bauen, Dateien auf den Server schieben – kein Prozess-Neustart, kein CMS-Abgleich, keine Downtime. Und wenn der Server neu startet, startet nichts mit – es liegen einfach Dateien da.

Was trotzdem geht (statisch heißt nicht statisch)

Zwei Anforderungen klangen zunächst nach „dafür braucht man doch einen Server”:

Das Kontaktformular sendet per Fetch an einen n8n-Workflow auf meinem Server – der validiert, benachrichtigt und archiviert. Das Formular selbst ist reines HTML und JavaScript, mit klickbarer E-Mail-Adresse als Fallback.

Der geschützte Workshop-Bereich war die interessanteste Nuss. Statt Login-Backend werden die Inhalte beim Build mit AES-256-GCM verschlüsselt und als Ciphertext in die Seite eingebettet. Der Browser entschlüsselt sie nach Passwort-Eingabe per WebCrypto (PBKDF2-Schlüsselableitung). Im ausgelieferten HTML steht kein Klartext – es gibt schlicht keinen Server, der etwas preisgeben könnte.

Und fürs Blog experimentiere ich mit einem wöchentlichen KI-Workflow, der aus meinen Arbeitsnotizen Themenvorschläge als Entwürfe generiert – veröffentlicht wird ausschließlich nach persönlicher Freigabe. Auch hier: Automatisierung als Zuarbeit, nicht als Autopilot.

Reduktion als Motiv

Beim Redesign ist mir aufgefallen, dass die Idee schon immer im Namen steckte: syfrt ist SEYFERT ohne Vokale. Weglassen, was nicht gebraucht wird – das ist jetzt wörtlich das Design-Motiv der Seite (schauen Sie sich die Startseite beim Laden an) und die Architektur-Entscheidung dahinter. Sogar im Logo steckt eine eigene Geschichte.

Fazit

Der Page Builder war das technisch spannendere Projekt. Die statische Seite ist die bessere Website: schneller, sicherer, wartungsfrei – und das Schreiben eines Blogposts ist jetzt eine Markdown-Datei statt eines CMS-Logins.

Die ehrlichste Erkenntnis: Referenz ist nicht, was den größten Stack zeigt, sondern was die richtige Entscheidung zeigt. Wenn Sie gerade überlegen, ob Ihre Firmenseite ein CMS braucht – fragen Sie mich, ich sage Ihnen auch, wenn die Antwort Nein ist.