Jahrelang war die Antwort auf die Frage „wo deploye ich das auf Cloudflare" einfach: statische Seiten und Frontends kamen auf Pages, und serverlose Logik kam auf Workers. 2026 ist diese Grenze verschwommen, denn Workers können jetzt statische Assets direkt ausliefern, was bedeutet, dass ein einzelner Worker deine ganze Website hosten kann, Frontend und Backend zusammen. Das hat Cloudflares eigene Empfehlung für neue Projekte verändert, und es lohnt sich zu verstehen, warum, bevor du dich für eine Seite entscheidest.
Dieser Leitfaden erklärt, was jedes Produkt ist, wie der Wechsel zu Static Assets die Entscheidung zwischen Cloudflare Pages vs Workers verändert hat, und gibt eine klare Empfehlung für neue Projekte und für alle, die sich fragen, ob sie migrieren sollten.
Kurzfassung
- Pages ist git-verbundenes Hosting für statische Seiten und Frontend-Frameworks, mit integriertem CI/CD und Preview-Deployments
- Workers ist Cloudflares serverlose Compute-Plattform, und sie liefert jetzt auch statische Assets aus, sodass sie vollständige Websites hosten kann
- Für neue Projekte 2026 empfiehlt Cloudflare Workers mit Static Assets, weil sie Frontend und Backend in einem Deployment vereinen
- Pages bleibt vollständig unterstützt; es gibt keinen Grund, ein bestehendes Pages-Projekt überstürzt zu verlagern
- Wähle nach Workflow: Pages für ein reines statisches Deploy per git-push, Workers für alles, was statische Inhalte mit dynamischer Logik mischt
Was Cloudflare Pages ist
Cloudflare Pages ist eine Plattform zum Deployen von Websites direkt aus einem git-Repository. Du verbindest ein GitHub- oder GitLab-Repo, Cloudflare führt deinen Build-Befehl aus, und das Ergebnis wird auf den globalen Edge deployt. Jeder Push erhält ein Preview-Deployment mit eigener URL, und ein Merge in deinen Produktions-Branch aktualisiert die Live-Seite. Das ist der klassische Jamstack-Workflow: Code pushen, deployte Seite bekommen.
Pages unterstützt dynamisches Verhalten auch über Pages Functions, die unter der Haube Workers sind, sodass du API-Routen und serverseitige Logik zu einer ansonsten statischen Seite hinzufügen kannst. Genau diesen Ansatz habe ich genutzt, um ein komplettes Benutzerregistrierungs- und Login-System auf Cloudflare Pages zu bauen, was zeigt, wie weit ein „statischer" Host gehen kann.
Was Cloudflare Workers ist
Cloudflare Workers ist die Plattform für serverloses Compute und serverloses Hosting: Code, der auf Cloudflares Netzwerk läuft, nah bei deinen Nutzern, ohne Server zu verwalten. Workers begannen als reine Funktionen für APIs, Middleware und Edge-Logik, und sie binden sich an den Rest der Plattform an, R2 , D1 , KV, Queues und Workers AI . Wenn du auf diesen Storage-Bindings aufbaust, machen meine kostenlosen Desktop-Apps sie einfach handhabbar: Easy Cloudflare R2 , Easy Cloudflare D1 und Easy Cloudflare KV .
Die zentrale Entwicklung von 2026 sind Static Assets. Ein Worker kann jetzt ein Verzeichnis mit statischen Dateien (HTML, CSS, JS, Bilder) direkt ausliefern, während der Worker alle dynamischen Routen übernimmt. Das bedeutet, dass ein einzelner Worker dein gebautes Frontend und deine API in einem Deployment hosten kann, etwas, das früher das Aufteilen der Arbeit zwischen Pages und Workers erforderte.
Was sich für Pages vs Workers geändert hat: Static Assets
Der Grund, warum dieser Vergleich überhaupt relevant ist, ist die Static-Assets-Fähigkeit. Wenn du früher ein React- oder Astro-Frontend plus eine Backend-API hattest, war die natürliche Aufteilung Pages für das Frontend und ein separater Worker für die API. Zwei Projekte, zwei Deployments, zwei Dinge, die zusammengeführt werden mussten.
Mit Static Assets auf Workers deployst du einmal. Der Worker liefert deinen statischen Build für normale Anfragen aus und führt deinen Code für API-Routen oder serverseitig gerenderte Seiten aus. Für Full-Stack-Frameworks und Apps, die statische und dynamische Inhalte mischen, ist das einfacher zu bauen, zu deployen und zu durchdenken. Deshalb verweist Cloudflare neue Full-Stack-Projekte jetzt auf Workers statt auf Pages.
Pages vs Workers: Im direkten Vergleich
| Kriterium | Cloudflare Pages | Cloudflare Workers |
|---|---|---|
| Hauptzweck | Git-verbundenes Seiten-Hosting | Serverloses Compute + Static Assets |
| Statisches Hosting | Ja (Kernfunktion) | Ja (über Static Assets) |
| Dynamische/Server-Logik | Pages Functions | Nativ |
| Git CI/CD + Previews | Integriert | Über CI-Integration / Wrangler |
| Bindings (R2, D1, KV, AI) | Ja | Ja, erstklassig |
| Am besten für | Reine statische/Jamstack-Seiten | Full-Stack-Apps und APIs |
| Empfehlung 2026 für neue Projekte | Weiterhin unterstützt | Bevorzugt |
Wann du Pages wählen solltest
Bei der Entscheidung Pages vs Workers ist Pages immer noch eine großartige Wahl, wenn:
- Du eine reine statische Seite oder einen Frontend-Framework-Build hast und den denkbar einfachsten git-push-Deploy-Workflow möchtest
- Du das integrierte CI/CD und die Preview-Deployments schätzt, ohne etwas konfigurieren zu müssen
- Deine dynamischen Anforderungen gering sind und gut von Pages Functions bedient werden
- Du bereits auf Pages bist und es funktioniert; es gibt keinen Nachteil beim Bleiben
Wann du Workers wählen solltest
Bei der Entscheidung Pages vs Workers ist Workers die bessere Wahl, wenn:
- Du eine Full-Stack-Anwendung baust, die statische Inhalte mit erheblicher serverseitiger Logik mischt
- Du Frontend und Backend in einem einzigen Deployment willst statt zweier koordinierter Projekte
- Du stark auf Bindings wie D1, R2, KV, Queues oder Workers AI setzt
- Du 2026 ein neues Projekt startest und dem aktuell empfohlenen Weg von Cloudflare folgen möchtest
- Du feingranulare Kontrolle über Routing, Caching und Request-Handling brauchst
Cloudflare Pages vs Workers: Solltest du migrieren?
Nein, nicht reflexartig. Wenn du ein funktionierendes Pages-Projekt hast, bleibt es vollständig unterstützt, und es gibt keine Frist, die einen Wechsel erzwingt. Migriere, wenn du einen konkreten Grund hast: Du fügst umfangreiche Backend-Logik hinzu, du willst ein aufgeteiltes Frontend/Backend in einem Deployment zusammenführen, oder du stößt an eine Pages-spezifische Grenze, die Workers löst.
Für Greenfield-Projekte beginne bei der Wahl zwischen Pages vs Workers mit Workers und Static Assets. Bei einem bestehenden, zufriedenstellenden Pages-Deployment lass es, bis ein echter Bedarf auftaucht. Der schlechteste Grund zu migrieren ist Neugier; der beste Grund ist das Vereinen einer Full-Stack-App, die du sonst aufteilen müsstest.
Wichtigste Erkenntnisse
- Pages ist git-verbundenes Hosting für statische und Jamstack-Seiten mit integriertem CI/CD und Previews
- Workers ist serverloses Compute, das jetzt auch statische Assets ausliefert, sodass es vollständige Websites hosten kann
- Static Assets ist die Änderung, die es einem einzelnen Worker erlaubt, Frontend und Backend gemeinsam zu hosten
- Für neue Full-Stack-Projekte 2026 ist Workers der von Cloudflare empfohlene Weg
- Pages bleibt vollständig unterstützt; migriere nur, wenn du einen konkreten Grund hast
- Bei der Entscheidung Cloudflare Pages vs Workers wähle Pages für reine statische Einfachheit und Workers für alles, was statische Inhalte mit echter Logik mischt
Häufig gestellte Fragen
Was ist der Unterschied zwischen Cloudflare Pages und Workers? Pages ist git-verbundenes Hosting für statische Seiten und Frontends mit integriertem CI/CD und Preview-Deployments. Workers ist Cloudflares serverlose Compute-Plattform. Die Grenze verschwamm 2026, weil Workers jetzt statische Assets ausliefern können, sodass ein Worker sowohl ein Frontend als auch ein Backend hosten kann.
Sollte ich für ein neues Projekt 2026 Pages oder Workers verwenden? Für die meisten neuen Full-Stack-Projekte ist Workers mit Static Assets jetzt Cloudflares empfohlene Wahl, weil sie Frontend und Backend in einem Deployment vereinen. Für eine rein statische Seite, bei der du den einfachsten git-push-Workflow möchtest, ist Pages weiterhin eine ausgezeichnete Option.
Wird Cloudflare Pages eingestellt? Nein. Pages bleibt vollständig unterstützt. Cloudflare lenkt neue Full-Stack-Projekte jetzt zu Workers, aber bestehende Pages-Projekte funktionieren weiter, und es gibt keine erzwungene Migration.
Kann Workers eine statische Website hosten? Ja. Mit der Static-Assets-Funktion kann ein Worker statische Dateien wie HTML, CSS, JS und Bilder direkt ausliefern und gleichzeitig dynamische Routen im Code übernehmen. Das ist es, was es einem einzelnen Worker erlaubt, eine ganze Website zu hosten.
Nutzen Pages und Workers die gleichen Bindings? Beide können Cloudflare-Bindings wie R2, D1, KV und Workers AI nutzen. Pages stellt sie über Pages Functions bereit, während Workers sie als erstklassig behandelt. Funktional erreichst du von beiden aus dieselben Plattformdienste.
Sollte ich meine bestehende Pages-Seite zu Workers migrieren? Nur wenn du einen konkreten Grund hast, etwa das Hinzufügen erheblicher Backend-Logik oder das Zusammenführen eines aufgeteilten Frontends und Backends in einem Deployment. Ein funktionierendes Pages-Projekt ist vollständig unterstützt und muss nicht verlagert werden.
Kommentare