Architektur und Betrieb einer persönlichen Website auf Cloudflare Workers

Fazit

Die Website kimura512.dev wird vollständig auf Cloudflare betrieben, indem statische Build-Ressourcen und Serverless-Logik auf Workers zusammengeführt werden. Ohne eigene Serververwaltung schrumpft das Release auf einen einzigen Befehl. Next.js läuft über vinext auf Workers, während Beitragsdaten versioniert in TypeScript vorliegen.

1. Verlässlicher Deployment-Ablauf

Der Livegang erfolgt durch pnpm run build gefolgt von wrangler deploy. Die Apex-Domain ist fest gebunden und Vorschau-Instanzen sind vom Produktiv-DNS getrennt.

2. Einheitliche Bereitstellung von Grafiken

Titelbilder liegen in public/blog/ und werden mittels sharp standardisiert, was Anzeigefehler ausschließt und externe Bildhoster überflüssig macht.

3. Edge-Sicherheit und Geheimnisschutz

WAF und HTTPS sichern die Website standardmäßig ab; Zugangsdaten liegen verschlüsselt in den Workers Secrets und gelangen nie ins Git-Repository.

4. Cache-Überprüfung am Edge

Nach Aktualisierungen prüfe ich die Inhalte im Inkognito-Fenster, um die korrekte Invalidierung der CDN-Caches zweifelsfrei nachzuvollziehen.

5. Ressourcenbewusste Performance

Aufwendige 3D-Hintergründe bleiben auf Startseite und About beschränkt; die Artikelseiten laden dadurch auf Mobilgeräten blitzschnell.

6. Dokumentation statt flüchtiger Logs

Da Live-Logs auf Workers flüchtig sind, werden wichtige Fehlerdiagnosen direkt in technischen Artikeln festgehalten.

7. Trennung von Preview und Live-Betrieb

Staging- und Produktions-Workers nutzen getrennte Kennungen; Passwörter werden ausschließlich verschlüsselt per CLI gesetzt.

8. Fokus auf die Hauptdomain

Experimentelle Nebenprojekte werden extern verlinkt, um die DNS-Verwaltung für den Einzelentwickler überschaubar zu halten.

Zusammenfassung

Workers verteilt weltweit, Git sichert die Historie und TypeScript prüft die Datenstrukturen: ein ideales Betriebsmodell für Solo-Entwickler.

Häufig gestellte Fragen

Q. Warum Workers statt eigenem VPS?
Es bietet globales CDN und Backend-APIs ohne jeglichen Administrationsaufwand.

Q. Kommt R2 zum Einsatz?
Blog-Grafiken liegen direkt im Repository; R2 dient ausschließlich eigenständigen Anwendungen.