LUSINI WebDev Vault

Cloudflare-Migration

5 Min. Lesezeit

Cloudflare-Migration

TL;DR

LUSINI soll vollständig von Netlify auf Cloudflare umgestellt werden (Workers Static Assets + bestehende CF-Worker). Functions sind bereits auf Cloudflare migriert (fn.lusini.com), Splash/CDN/Routing/A/B/Redirects/CSP laufen ebenfalls schon im CF Worker. Verbleibender Netlify-Anteil: Static Hosting für 16 Locales × 2 Envs sowie Gatsby SSR (PDP, Category) und DSG.

Zentraler Befund: Cloudflare bietet keinen offiziellen Adapter für Gatsby SSR/DSG. Ein eigener Adapter wird vom Team als zu fehleranfällig eingeschätzt. Daraus folgen zwei realistische Wege:

  1. Vorgelagerte Migration auf Next.js (Empfehlung) — danach saubere Cloudflare-Anbindung über offizielle Tooling-Pfade (OpenNext / @opennextjs/cloudflare oder Vercel-kompatible Adapter).
  2. Refactor SSR/DSG → CSR + reines SSG und direkter Wechsel zu Workers Static Assets unter Beibehaltung von Gatsby. Risiken bei SEO/LCP für PDP und Category.

Ein Hybrid-/Parallelbetrieb mit Netlify ist explizit nicht erwünscht.

Bestandsaufnahme (Ist-Zustand)

Was Netlify heute noch leistet:

  • Static Hosting der Gatsby-Builds: 16 Locales × 2 Envs = ~32 Sites
  • Gatsby SSR über getServerData in PDP und CategorySSR
  • Gatsby DSG / SSR-On-Demand-Builder
  • Adapter gatsby-adapter-netlify@1.4.0
  • A/B-Branch-Deploys — Splash-Worker rewritet auf diese URLs für Cache-Isolation
  • Preview-Deploys → {hash}.lusini.dev via Splash-Worker + KV
  • _redirects über Gatsby createRedirect und Fetch des Redirect-Caches via Netlify File API
  • GitHub Actions Build → Artefakt → netlify-branch-deploy entpackt, deploy via Netlify CLI

Was bereits auf Cloudflare läuft:

  • Splash-Worker lusini_splash_cloudflare: Reverse-Proxy zu Netlify, Edge-Caching, KV-Redirects (LUCID/n8n), statische Redirects, Trailing-Slash, A/B-Cookie-Split + URL-Rewrite, Preview-Proxy, CSP-Generator, Security-Headers, WAF
  • Functions-Worker lusini_functions_cloudflare (Hono) auf fn.lusini.com / fn-dev.lusini.com: newsletter, pmk, creditsafe, kvk, shopware, share-cart, configurator, raffle, form-submit. Vollständig produktiv, Netlify Functions sind abgelöst.

Build-Groesse pro Locale (Stand develop):

  • du -sh public/ = 21 MB
  • find public -type f | wc -l = 305 Files
  • → Weit unterhalb der Workers-Static-Assets-Limits (~20.000 Files, 25 MiB pro Asset). Kein Limit-Risiko.

Kostenbild:

  • Letzte Netlify-Rechnung Feb 2026 (für Aug 2025): $1.328
    • $500 Bandwidth Overage
    • $828 Edge Functions Overage — entfällt seit Functions-Migration komplett
    • Netlify Business Plan Base bleibt
  • Cloudflare Workers Paid: $5/Monat account-wide; Asset-Requests free unlimited; KV/R2 vernachlässigbar; Service-Bindings zwischen Workern ohne Sub-Request-Kosten
  • Realistische monatliche Ersparnis nach Vollumstellung: ~$400–700

Strategische Entscheidung: Pfad A vs. Pfad B

Pfad A — Vorgelagerte Migration auf Next.js, anschliessend Cloudflare

Vorgehen: Erst Next.js-Migration als eigenständiges Projekt, danach Cloudflare-Deployment via offizielle Tooling-Pfade (z. B. @opennextjs/cloudflare, alternativ Vercel-kompatibles Build-Output-Format).

Pro:

  • Offizielle, gewartete Adapter — kein Custom-Code, der bei jedem Gatsby/CF-Update bricht
  • Next.js App Router unterstützt SSR, RSC, ISR/DSG nativ
  • Größerer Talent-Pool, modernes React-Ökosystem
  • Einmal-Investition löst gleichzeitig SSR-Hosting-Frage, Performance-Themen und Vendor-Risiken
  • Preview-Deploys, Edge-Functions, Image-Optimization sind in Next.js/CF-Stack Standard

Contra:

  • Größtes Projekt der drei Optionen — vermutlich Quartal(e) statt Wochen
  • Risiko von Feature-Regressionen während der Umstellung
  • Doppelte Code-Pflege während Übergangsphase
  • Bis dahin bleibt Netlify mit allen aktuellen Kosten produktiv

Geeignet wenn: Next.js sowieso strategisch geplant ist und Cloudflare-Wechsel als Folgeschritt akzeptabel ist.

Pfad B — SSR/DSG → CSR + SSG-only, direkt auf Cloudflare

Vorgehen: PDP- und Category-SSR auf Client-Side Rendering umstellen. Gatsby produziert dann nur noch reines SSG. Deployment auf Workers Static Assets ohne Adapter-Bedarf.

Pro:

  • Kein Custom-Adapter nötig
  • Schnellster Pfad zu Netlify-loser Architektur (Wochen statt Quartale)
  • Cloudflare Workers Static Assets ist vollständig kompatibel mit reinem SSG
  • Build-Größe (21 MB / 305 Files) unproblematisch

Contra:

  • SEO-Risiko: PDP und Category liefern aktuell server-gerenderte Inhalte für Crawler
  • LCP-Verschlechterung möglich: Inhalte erscheinen später, da Client erst nach Hydration nachlädt
  • Helmet/Meta-Tags auf SSR-Inhalten müssen anders gelöst werden
  • Refactoring-Aufwand in den betroffenen Templates ist nicht trivial, aber abschätzbar

Geeignet wenn: Next.js mittelfristig nicht ansteht und SEO-Risiken durch sorgfältiges Refactor mitigierbar sind.

Empfehlung

Pfad A ist der nachhaltigere, aber größere Schritt. Pfad B ist der pragmatische, schnellere Weg zur Cloudflare-Konsolidierung. Ein expliziter Strategie-Termin mit Engineering- und Produkt-Lead wird empfohlen, bevor Implementierungsphasen geplant werden.

Architektur-Bausteine (gemeinsam fuer beide Pfade)

  1. Static Assets pro Locale — entweder ein Worker pro Locale oder ein Multi-Locale-Worker mit Pfad-Routing. Empfehlung: ein Worker pro Locale, parallel zur heutigen Site-Struktur, einfacher Roll-out.
  2. Splash-Worker erweitern — Origin-URL pro Locale wird auf den jeweiligen Static-Assets-Worker umgestellt; Service-Bindings zwischen Workern (Sub-Requests kostenfrei).
  3. A/B-Testing ohne Netlify-Branch-URLs — pro Variante ein eigenständiger Worker-Deployment-Name. Splash-Worker entscheidet per Cookie und routet via Service Binding. Cache-Isolation entsteht automatisch durch unterschiedliche Worker-Origins.
  4. Preview-Deploys — pro Hash ein eigener Worker oder ein Multi-Tenant-Worker, der Assets aus R2 unter Pfad {hash}/... serviert. KV-Lookup im Splash-Worker bleibt unverändert.
  5. Redirect-Cache — Migration weg von Netlify File API hin zu Cloudflare KV oder R2.
  6. GitHub Actions Refactor — neue Workflows mit wrangler deploy; per-Locale Secrets.
  7. WAF-Regel an neue Worker-Hostnames binden.
  8. Cleanup — gatsby-adapter-netlify, netlify.toml, netlify-branch-deploy, .netlify/-Pfade, Netlify-Sites, Plan-Downgrade.

Migrations-Phasen (Pilot-First)

Phase 0 — Strategie-Entscheidung Pfad A vs. Pfad B

Phase 1 — Vorbereitung Cloudflare-Plattform (wrangler.toml-Templates, KV-Namespaces, R2-Bucket, Splash-Worker-Routing-Tabelle, Redirect-Cache-Migration)

Phase 2 — SSR/DSG-Refactor (nur Pfad B: PDP + Category auf CSR, SEO-Tags via SSG, DSG-ODB eliminieren)

Phase 3 — Pilot Locale hr-hr (neuer GH-Actions-Workflow parallel, 1–2 Wochen Real-User-Monitoring)

Phase 4 — Pilot Locale pt-pt + A/B-Mechanik + Preview-Migration

Phase 5 — Roll-out übrige 14 Locales

Phase 6 — Cleanup (gatsby-adapter-netlify, netlify.toml, netlify-branch-deploy entfernen, Plan kündigen)

Phase 7 — Hardening (Lasttest, CF Pro-Tier-Limits, Sentry-Quotas, Monitoring-Dashboards)

Aufwandsschaetzung

  • Pfad A (Next.js vorgelagert): Quartal(e) für Next.js-Migration + ~6–8 Personenwochen für Cloudflare-Roll-out
  • Pfad B (CSR-Refactor + Direkt-Migration): ~10–14 Personenwochen Gesamt

Verification

  1. SEO-Parität: View-Source-Vergleich PDP, Category, Home; Google Search Console Coverage-Report
  2. Performance: Lighthouse-CI-Vergleich (LCP, INP, CLS) auf Pilot-Locales
  3. Funktional: E2E auf Pilot-Locale (Cart, Checkout, A/B-Cookie-Set, Preview-Hash-Zugriff, Redirect-Verhalten)
  4. A/B: Cookie-Split-Verteilung und Cache-Isolation pro Variante verifizieren
  5. Functions-Integration: Share-Cart, PMK, Newsletter-Submit unverändert (separater Worker)
  6. Cache-Hit-Rate via CF Analytics vs. heutige Netlify-Bandwidth-Werte

Scope-Abgrenzung

Im Scope: Static Hosting, SSR/DSG-Lösung, A/B, Preview, Redirects, GH Actions, Cleanup — 16 Locales × 2 Envs

Ausserhalb Scope: Migration der bereits abgelösten Netlify Functions, Änderungen an Splash-Worker-Logik außerhalb Routing-Tabelle und A/B-Pattern, Änderungen am Functions-Worker, Netlify-Hybrid-Betrieb

Graphansicht