Von kritischen CVEs zur selbst gehosteten Website – Mein Rebuild mit Astro
Warum ein eingekauftes Next.js-Theme mit kritischen Sicherheitslücken der Startschuss für einen kompletten Neuaufbau meiner Website war – und wie ich dabei auf Astro, Decap CMS und meinen eigenen Netcup-Server gesetzt habe.
Es fing harmlos an: Ein gekauftes Theme, schick designt, Next.js-basiert, einigermaßen schnell deployed auf Vercel. Fertig war meine neue, persönliche Website. Oder so dachte ich.
Das Problem: CVEs und tote Maintenance
Einige Zeit später kam die unangenehme Überraschung. Beim Durchsehen meiner Abhängigkeiten tauchten kritische CVEs auf – Sicherheitslücken in den npm-Paketen des Themes. Der Theme-Autor? Nicht mehr aktiv. Letzter Commit? Über ein Jahr alt. Issues im Repo? Unbeantwortet.
Das ist wohl das typische Dilemma mit eingekauften Themes: Du kaufst dir Geschwindigkeit ein, aber du kaufst dir auch die technischen Schulden des Autors mit. Und wenn der Autor das Projekt aufgibt, bist du der, der die Konsequenzen trägt.
Dazu kam ein weiterer Punkt: Erweiterbarkeit. Ich wollte ein Kontaktformular mit Spam-Schutz, Analytics die DSGVO-konform sind, eine CMS-Anbindung für einfaches Bearbeiten von Inhalten. Im eingekauften Theme war das nahezu unmöglich – zu viel Blackbox, zu wenig Übersicht, zu viel Abhängigkeit von Entscheidungen die jemand anderes vor Jahren getroffen hatte. Als technischer Laie ohne tiefes Next.js-Wissen war da schlicht keine sinnvolle Handhabe.
Die Entscheidung: Neu bauen, richtig machen
Ich hätte das Theme patchen können. Abhängigkeiten updaten, Workarounds bauen, hoffen dass nichts bricht. Aber ehrlich gesagt war das der Moment, in dem ich mir sagte: Wenn ich es schon anfasse, dann richtig.
Die Anforderungen waren klar:
- Volle Kontrolle über Code, Hosting und Daten
- Kein Vendor Lock-in – heute netcup, morgen woanders
- CMS damit ich Inhalte ohne Deployment-Pipeline ändern kann
- Erweiterbar für Formulare, Analytics und was auch immer noch kommt
- DSGVO-konform von Anfang an, nicht als Nachgedanke
- Performant – statisch wo möglich, dynamisch wo nötig
Der neue Stack
Nach einiger Recherche fiel die Wahl auf Astro 5. Astro baut standardmäßig statisches HTML – kein JavaScript-Overhead wo keiner gebraucht wird. Content Collections ermöglichen typsichere MDX-Artikel. Und der Output lässt sich problemlos in einem Docker-Container betreiben.
Als CMS kam Decap CMS zum Einsatz. Es speichert Inhalte direkt als Markdown- und YAML-Dateien im GitHub-Repository – kein eigener Backend-Server, keine Datenbank für Content, keine monatlichen SaaS-Kosten. Das Bearbeiten eines Blog-Artikels triggert automatisch einen neuen Build.
Das Hosting läuft auf meinem netcup Root Server – einem deutschen Anbieter, physisch in Deutschland. Docker Compose, Nginx Proxy Manager für SSL, GitHub Actions für automatisches Deployment. Keine Magie, nur solide Infrastruktur.
Das Design: Terminal-Ästhetik mit Absicht
Neben den technischen Entscheidungen war mir das Design wichtig. Kein generisches Portfolio-Template, sondern etwas das zu mir passt – und zu dem was ich tue.
Herausgekommen ist ein dunkles Terminal-Design: JetBrains Mono als Monospace-Schrift, Lime-Grün als Akzentfarbe, kubectl- und helm-Kommandos als Gestaltungselemente, eine Typewriter-Animation im Hero-Bereich. Die Sidebar navigiert wie eine IDE, die 404-Seite gibt vor git log this-page auszuführen – und findet natürlich nichts.
Das ist kein Selbstzweck. Es spiegelt wider womit mein Team und ich jeden Tag arbeiten: Kubernetes, Container, CI/CD und die Orchestierung meines Teams. Und es macht die Website zu etwas Eigenem – nicht zu einem von tausend gleich aussehenden Portfolio-Sites.
Wie das alles entstanden ist: Mit KI, aber nicht automatisiert
Ich bin kein Webentwickler. Kubernetes, technisches Interesse, wobei noch am ehesten Teamführung – das sind meine Felder. HTML, CSS und TypeScript deutlich weniger.
Den Rebuild habe ich deshalb gemeinsam mit Claude umgesetzt – dem KI-Assistenten von Anthropic. Aber nicht so wie man sich das vielleicht vorstellt: Kein Claude Code der autonom auf meinem Server werkelt, kein automatisches Ausführen von Skripten. Ich habe bewusst den klassischen Chat genutzt und jeden Terminal-Befehl selbst ausgeführt.
Das war eine bewusste Entscheidung. Ich wollte verstehen was passiert – nicht nur ein Ergebnis haben. Wenn Claude mir einen docker compose-Befehl erklärt und ich ihn selbst eintipps, lerne ich dabei. Wenn ein Fehler auftritt, verstehe ich ihn besser weil ich den Kontext kenne. Und ich behalte die volle Kontrolle darüber was auf meinem Server passiert.
Das Ergebnis: Ich habe in diesem Projekt mehr über Astro, Docker, Nginx, GitHub Actions und Webentwicklung gelernt als in den Jahren davor mit dem eingekauften Theme zusammen. Die KI hat mir geholfen schneller voranzukommen – aber das Lernen und die Kontrolle blieben bei mir.
Was dabei herausgekommen ist
Die neue Website lädt schnell, ist vollständig unter meiner Kontrolle und kostet mich außer dem Server nichts Zusätzliches. Änderungen an Texten, Blog-Artikeln oder Projekten mache ich bequem über das CMS-Backend – ohne Terminal, ohne Deployment, einfach speichern und fertig.
Und das Beste: Ich kann sie erweitern. Was im alten Theme unmöglich oder zumindest undurchschaubar war, ist jetzt Realität:
- Matomo Analytics – selbst gehostet, cookielos, DSGVO-konform ohne Cookie-Banner
- Mehrschichtiger Spam-Filter im Kontaktformular mit Cloudflare Turnstile
- E-Mail-Obfuskation per ROT13 damit Bots meine Adresse nicht abgreifen können
- Self-hosted Fonts – kein Request mehr zu Google Fonts
- Eine 404-Seite im Terminal-Stil die
kubectl,helmundgitbemüht um die fehlende Seite zu finden
Jede dieser Funktionen hätte ich im alten Setup nicht sinnvoll umsetzen können. Jetzt weiß ich genau wo der Code dafür sitzt – und wie er funktioniert.
Was ich mitgenommen habe
Eingekaufte Themes sind verlockend. Sie sparen Zeit, sie sehen gut aus, sie funktionieren – zunächst. Aber sie haben einen Preis der sich erst später zeigt: Abhängigkeit vom Autor, mangelnde Kontrolle über Abhängigkeiten, und im schlimmsten Fall Sicherheitslücken die du nicht selbst schließen kannst.
Der Rebuild hat deutlich mehr Zeit gekostet als das ursprüngliche Theme-Setup. Aber am Ende habe ich eine Website die ich vollständig verstehe, vollständig kontrolliere und die mir niemand wegnehmen kann weil irgendein SaaS-Anbieter seine Pricing-Strategie ändert.
KI kann dabei ein hervorragender Partner sein – wenn man sie als Werkzeug nutzt, nicht als Autopilot. Die Befehle selbst ausführen, die Konzepte verstehen, die Kontrolle behalten. Das ist langsamer. Aber es ist nachhaltiger.
Manchmal ist der längere Weg der richtigere.
