---
title: "Warum kondevs.com auf Cloudflare Pages und Workers läuft"
description: "Wie kondevs.com auf Cloudflare Pages, Workers, KV und R2 läuft: am Edge gerenderte Seiten, Deployments über eine Vorschau, DDoS-Schutz und was das kostet."
canonical: "https://www.kondevs.com/de/content-hub/kondevs-cloudflare-workers-architecture/"
language: "de"
type: "article"
author: "https://www.kondevs.com/authors/stoyan-kondev/"
published: "2026-11-11T22:20:36.482Z"
modified: "2026-11-11T22:20:36.482Z"
image: "https://www.kondevs.com/assets/images/content/de/kondevs-cloudflare-workers-architecture/og.jpeg"
tags: ["cloudflare-workers", "edge-computing", "serverless-architektur", "ddos-schutz", "website-architektur", "Middleware", "KI-Agent", "IBM webMethods", "Camunda"]
---

> Den vollständigen Index dieser Website finden Sie in [llms.txt](https://www.kondevs.com/llms.txt); die ganze Website in einer Datei: [llms-full.txt](https://www.kondevs.com/llms-full.txt).

# Warum kondevs.com auf Cloudflare Pages und Workers läuft

Am Edge gerenderte Seiten, KV und R2 als Speicher, jedes Release zuerst in einer Vorschau geprüft: die Architektur und was sie kostet.

Fallstudien 11. November 2026 7 Min. Lesezeit

Von [Stoyan Kondev](https://www.kondevs.com/de/authors/stoyan-kondev/)

![Ein leuchtendes Globus-Symbol inmitten konzentrischer, durchscheinender Schutzschilde, Lichtstrahlen ziehen über eine Weltkarte](https://www.kondevs.com/cdn-cgi/image/width=1200,quality=80,format=auto/assets/images/content/de/kondevs-cloudflare-workers-architecture/featured.jpeg)

## Das Wichtigste in Kürze

- kondevs.com ist ein Cloudflare-Pages-Projekt: Seine Pages Functions laufen auf der Workers-Runtime und rendern jede Seite am Edge, ohne Origin-Server, der gepatcht oder skaliert werden müsste.
- KV speichert alle Artikel und die Indizes, aus denen die Artikellisten gelesen werden, R2 die Bilder der über die API veröffentlichten Artikel; D1 und Durable Objects nutzt die Website nicht.
- Jedes Release wird aus dem Repository gebaut, in einer Vorschau bereitgestellt und dort geprüft, dann mit einem Wrangler-Befehl in die Produktion gebracht und live geprüft; Deployments per Git-Push sind bewusst abgeschaltet.
- Cloudflares Netzwerk fängt DDoS-Angriffe ab, und der eigene Code der Website ergänzt strikte Sicherheits-Header, Rate Limits für ihre APIs und die Bereinigung veröffentlichter Artikel.
- Cloudflare ist günstig, aber nicht kostenlos: Jeder Seitenaufruf auf kondevs.com durchläuft die Middleware und zählt als Workers-Anfrage, während die statischen Dateien an den Functions vorbei kostenlos ausgeliefert werden; nur die Feeds und llms-full.txt liegen im Edge-Cache.

Im ersten Halbjahr 2026 wehrte Cloudflare 23,2 Millionen DDoS-Angriffe auf der Netzwerkschicht ab. Davon überschritten 935 die Marke von 1 Tbit/s. In diesem Umfeld bewegt sich jede Unternehmenswebsite, ob das Team dahinter an Sicherheit denkt oder nicht.

Als wir www.kondevs.com neu aufgebaut haben, lautete die Frage nicht: „Welcher Hosting-Anbieter ist am günstigsten?“ Die Frage war: Welche Architektur verschafft einem kleinen, spezialisierten Beratungshaus für Unternehmens-IT dieselbe Performance am Edge, dasselbe Sicherheitsniveau und dieselbe Einfachheit im Betrieb, die ein großes Plattformteam entwerfen würde, ohne dessen Personal und Budget?

Die Antwort war am Ende Cloudflares Entwicklerplattform. Nicht, weil sie in Mode ist, sondern weil ihre Architektur eine saubere Trennung der Zuständigkeiten erzwingt. Das passt zu Websites, die schnell und geschützt sein müssen und sich von einem Team pflegen lassen sollen, das auch noch anderes zu tun hat.

## Die Architektur: zustandslos am Edge, Speicher je nach Zweck

Cloudflare Workers führen JavaScript und TypeScript in Cloudflares globalem Netzwerk aus. Anfragen werden nahe beim Nutzer verarbeitet, nicht in einem Rechenzentrum, das bei Vertragsunterzeichnung festgelegt wurde. Workers nutzen die V8-Engine in leichtgewichtigen Isolates, statt für jede Anfrage einen vollständigen Container zu starten. Das senkt den Startaufwand gegenüber klassischen Serverless-Funktionen; die Latenz von Anfang bis Ende hängt aber weiterhin von nachgelagerten Aufrufen und Speicherzugriffen ab. Feste Kaltstartzeiten sollte hier niemand versprechen.

Das entscheidende Designprinzip: Workers sind zustandslos. Es ist nicht garantiert, dass Variablen im Arbeitsspeicher zwischen zwei Anfragen erhalten bleiben. Die nächste Anfrage landet womöglich bei einer anderen Instanz oder an einem anderen Standort. Das ist gewollt und keine Einschränkung. Es zwingt dazu, sich zu überlegen, wohin der Zustand tatsächlich gehört.

Cloudflare beantwortet diese Frage mit spezialisierten Bindings. KV für weltweit verteilte Key-Value-Lesezugriffe (Konfiguration, gecachte API-Antworten). D1 für relationale Daten mit SQLite-Semantik, Point-in-Time-Recovery und optionaler globaler Lesereplikation. R2 für Objektspeicher mit S3-kompatibler API. Durable Objects für die seltenen Fälle, in denen Sie eine weltweit eindeutige, single-threaded und zustandsbehaftete Instanz brauchen: koordinierte Zähler, Session-Locks, Zusammenarbeit in Echtzeit.

Das Muster, das Cloudflares eigene Dokumentation empfiehlt: Ein zustandsloser Worker übernimmt Authentifizierung, Validierung und Routing am Edge und überlässt den Zustand über Bindings dem passenden Dienst. Bei kondevs.com ist die Plattform Cloudflare Pages: Die Pages Functions der Website werden zu einem einzigen Worker gebündelt, der jede Seite am Edge rendert und Routing und Header übernimmt. KV speichert alle Artikel und die Indizes, aus denen die Artikellisten gelesen werden, und R2 hält die Bilder der Artikel, die über die API der Website veröffentlicht werden (die wenigen im Repository gepflegten Artikel bringen ihre Bilder mit der Website mit). Seit Oktober 2026 ist die Website zweisprachig: Deutsche Seiten liegen unter /de/, deutsche Artikel unter eigenen KV-Schlüsseln. D1 und Durable Objects nutzt die Website nicht: Eine Content-Website dieser Größe braucht keines von beiden. Es gibt keinen Origin-Server, der gepatcht, skaliert oder um 2 Uhr nachts betreut werden müsste.

Ein Detail ist für Caching und Kosten gleichermaßen wichtig. Die Middleware der Website läuft bei jeder Seite, jedem Feed und jeder maschinenlesbaren Datei; so setzt ein einziges Stück Code die Sicherheits-Header, die Weiterleitungen und die maschinenlesbaren Link-Header in jeder Antwort. CSS, JavaScript, Bilder, Schriften und Icons umgehen sie: Eine Datei _routes.json schickt sie direkt an Cloudflares Server für statische Assets, sodass sie keine Functions aufrufen. HTML-Seiten werden bei jeder Anfrage gerendert und tragen ein ETag; ein wiederkehrender Browser erhält deshalb eine kurze 304-Antwort statt der ganzen Seite. Die RSS- und JSON-Feeds und llms-full.txt liegen in Cloudflares Edge-Cache, und CSS und JavaScript tragen einen Inhalts-Hash in ihrer Adresse, sodass Browser sie ein Jahr lang behalten.

## Deployment: ein Befehl, danach die Prüfung

Cloudflare Pages kann eine Website bei jedem Push in ein Git-Repository bauen. KONDEVS hat das bewusst abgeschaltet: Jedes Release wird aus dem Repository gebaut, zuerst unter einer Vorschauadresse bereitgestellt und dort geprüft, dann mit einem einzigen Wrangler-Befehl in die Produktion gebracht und auf der Live-Website erneut geprüft. Pages Functions (Workers) liefern das dynamische Verhalten (serverseitiges Rendering, eigene Header, Weiterleitungen, die Publishing-API) und binden Speicher über Bindings in der Konfigurationsdatei an. Das Deployment-Modell kennt jeder Entwickler, der mit CI/CD gearbeitet hat; nur ist das Ziel ein globales Edge-Netzwerk statt einer einzelnen Region.

Für ein Beratungsunternehmen wie KONDEVS hat das handfeste Folgen für den Betrieb. Die Website pflegen Enterprise-Integrationsarchitekten, kein eigenes DevOps-Team. Die Deployment-Pipeline muss so einfach sein, dass eine Inhaltsänderung oder eine angepasste Routing-Logik nicht zum eigenen Projekt wird, und so bewusst angelegt, dass nichts versehentlich in die Produktion gelangt. Ein Build, eine Vorschau, ein Deploy-Befehl für die Produktion und eine Prüfung auf der Live-Website leisten genau das.

## Sicherheit, die Sie nicht selbst bauen müssen

Hier zahlt sich die Architektur für Unternehmenswebsites aus. Cloudflares DDoS-Bericht für das erste Halbjahr 2026 zeigt: Rund 90 % der Angriffe auf der Netzwerkschicht endeten innerhalb von 10 Minuten, und fast 97 % lagen unter 500 Mbit/s. Kurz, häufig, automatisiert. Genau der Traffic, der die Performance verschlechtert und die Bandbreitenkosten in die Höhe treibt, lange bevor jemand einen Vorfall bemerkt, der Schlagzeilen machen würde.

Eine von Tasrie IT Services veröffentlichte Fallstudie beschreibt, was geschah, als eine saudische Mobilitätsplattform Cloudflares WAF-Regeln, Bot-Kontrollen, Rate Limiting und DDoS-Schutz konfigurierte: Der automatisierte Traffic, der den Origin-Server erreichte, sank von rund 38 % auf unter 3 %. Die Bandbreite am Origin ging um 62 % zurück. Die mediane Time to First Byte verbesserte sich von 380 ms auf 95 ms. Diese Zahlen hängen von der Umsetzung ab: Je nach Caching-Strategie, Leistung des Origin-Servers und Konfiguration fallen die Ergebnisse anders aus. Die Richtung ist aber eindeutig: Filterung und Caching am Edge entlasten den Origin und verbessern die wahrgenommene Geschwindigkeit.

Für kondevs.com heißt das: Cloudflares Netzwerk fängt DDoS-Angriffe auf der Netzwerkschicht ab, bevor sie die Website erreichen. HTTP-Anfragen, die seine Filter passieren, durchlaufen den eigenen Code der Website, und der steuert den Rest bei: strikte Sicherheits-Header (CSP, HSTS) in jeder Antwort, Rate Limits für ihre APIs und die Bereinigung (Sanitizing) jedes veröffentlichten Artikels. KI-Crawler und KI-Agenten sind bewusst zugelassen, denn die Website ist dafür gebaut, von ihnen gelesen zu werden. Die Website braucht keine separate Security-Appliance, keinen eigenen CDN-Vertrag und keinen gesonderten Hosting-Anbieter. Eine Plattform übernimmt die Filterung der Anfragen, das Caching und die Auslieferung.

## Kosten: niedrig, aber nicht null

Das Versprechen „ohne Kosten“ verdient einen genauen Blick. Cloudflares kostenloser Tarif (Free Tier) ist für Websites mit wenig Traffic und für private Projekte großzügig. Deployments auf Pages sind kostenlos. Für Workers gibt es ein kostenloses Kontingent. Bei R2 ist der ausgehende Datenverkehr (Egress) kostenlos. Cloudflare rechnet aber nutzungsabhängig ab, und die Kosten steigen mit Anfragen, Speicher und Produktnutzung. Eine Unternehmenswebsite mit moderatem Traffic lässt sich für sehr wenig Geld betreiben. Eine Anwendung mit hohem Traffic, vielen D1-Abfragen und großem R2-Speicher wird nicht kostenlos sein.

Ehrlich formuliert: Cloudflares Architektur erlaubt es, gezielt auf niedrige Kosten hin zu planen. Man verlagert Arbeit an den Edge (gecachte Lesezugriffe, statische Assets, schlanke Workers) und reserviert kostenpflichtige Ressourcen (D1-Schreibzugriffe, Durable Objects, große R2-Buckets) für das, was sie wirklich braucht. Das Kostenmodell belohnt gute Architektur. Das ist ein anderes Versprechen als „kostenlos“, und ein nützlicheres.

Die Website kondevs.com zeigt den Zielkonflikt. Jeder Seitenaufruf durchläuft die Middleware der Website und zählt als Workers-Anfrage. Bei statischen Dateien ist es anders: Cloudflare liefert sie kostenlos und unbegrenzt aus, solange sie keine Functions aufrufen. Deshalb leitet die Website ihre CSS- und JavaScript-Dateien, Bilder, Schriften und Icons mit einer Datei _routes.json an den Functions vorbei. Bis Oktober 2026 liefen auch sie durch die Middleware, und jede einzelne zählte als Anfrage. Eine Website mit deutlich mehr Traffic würde zusätzlich mehr ihrer Seiten im Edge-Cache halten.

## Was das für Unternehmenswebsites bedeutet

KONDEVS berät regulierte Unternehmen zur Integrationsarchitektur: webMethods, Camunda, SEEBURGER, IBM Sterling, die gesamte gewachsene Brownfield-Landschaft. Dass die eigene Website auf Cloudflare Pages und Workers läuft, ist keine Aussage über den Ersatz von Enterprise-Middleware. Es ist die praktische Umsetzung eines Prinzips, das wir überall anwenden: Zuständigkeiten sauber trennen, Logik in die richtige Schicht legen und sicherstellen, dass jemand erklären kann, wie das System im Fehlerfall reagiert.

Pages Functions auf der Workers-Runtime übernehmen Rendering und Routing. KV hält die Inhalte, R2 die Bilder. Cloudflares Netzwerk fängt Angriffe auf der Netzwerkschicht ab, bevor sie die Anwendungslogik erreichen, und der Code setzt seine eigenen Header und Limits durch. Jede Komponente hat eine klar definierte Aufgabe, einen klar benannten Verantwortlichen und ein beobachtbares Verhalten. Dahinter steht dasselbe Denken wie hinter einer Integrationsschicht mit klarer Governance in einem regulierten Unternehmen, nur angewendet auf eine Website.

Der Neuaufbau von kondevs.com ist ein kleiner Beleg für eine größere Überzeugung: Architekturentscheidungen, die an den Grenzen zwischen Komponenten Klarheit erzwingen, ergeben Systeme, die schneller sind, günstiger im Betrieb und schwerer aus dem Tritt zu bringen. Ob die Grenze zwischen einem Worker und einem KV-Namespace verläuft oder zwischen einem API-Gateway und einer Process Engine im Backend: Das Prinzip gilt. Saubere Trennung ist keine Eleganz um ihrer selbst willen. Sie ist eine Versicherung für den Betrieb.

## Häufige Fragen

### Worauf läuft kondevs.com?

Auf Cloudflare Pages: Die Pages Functions der Website laufen auf der Workers-Runtime und rendern jede Seite am Edge, KV speichert die Artikel und ihre Indizes, und R2 hält die Bilder der über die API veröffentlichten Artikel. Es gibt keinen Origin-Server, keine D1-Datenbank und keine Durable Objects.

### Wie wird kondevs.com bereitgestellt?

Jedes Release wird aus dem Repository gebaut, in einer Vorschau bereitgestellt und dort geprüft, dann mit einem Wrangler-Befehl in die Produktion gebracht und auf der Live-Website geprüft. Automatische Deployments per Git-Push sind bewusst abgeschaltet, damit nichts versehentlich in die Produktion gelangt.

### Wie ist die Website geschützt?

Cloudflares Netzwerk fängt DDoS-Angriffe auf der Netzwerkschicht ab, bevor sie die Website erreichen. Der eigene Code der Website ergänzt strikte Sicherheits-Header (CSP, HSTS) in jeder Antwort, Rate Limits für ihre APIs und die Bereinigung jedes veröffentlichten Artikels.

### Ist der Betrieb einer Website auf Cloudflare kostenlos?

Nicht ganz. Der kostenlose Tarif ist für Websites mit wenig Traffic großzügig, aber die Abrechnung ist nutzungsabhängig, und die Kosten steigen mit Anfragen, Speicher und Produktnutzung. Auf kondevs.com durchläuft jeder Seitenaufruf die Middleware der Website und zählt als Workers-Anfrage; die statischen Dateien umgehen die Functions und bleiben so kostenlos und unbegrenzt.

## Quellen

1. [Cloudflare DDoS Threat Report H1 2026: 1 Tbps attacks soar as DNS floods and geopolitical tensions drive a new wave, Cloudflare](https://blog.cloudflare.com/ddos-threat-report-2026-h1/)
2. [How a Saudi Mobility Platform Hardened Its Booking and Payment APIs with Cloudflare, Tasrie IT Services](https://tasrieit.com/case-studies/saudi-mobility-platform-cloudflare-waf-security)
3. [How Workers works, Cloudflare Docs](https://developers.cloudflare.com/workers/reference/how-workers-works/)
4. [Rules of Durable Objects, Cloudflare Docs](https://developers.cloudflare.com/durable-objects/best-practices/rules-of-durable-objects/)
5. [Choose a data or storage product, Cloudflare Docs](https://developers.cloudflare.com/workers/platform/storage-options/)
6. [Cloudflare D1, Cloudflare Docs](https://developers.cloudflare.com/d1/)
7. [Pricing (Cloudflare Workers), Cloudflare Docs](https://developers.cloudflare.com/workers/platform/pricing/)
8. [Limits (Cloudflare Pages), Cloudflare Docs](https://developers.cloudflare.com/pages/platform/limits/)
9. [Pricing (Pages Functions), Cloudflare Docs](https://developers.cloudflare.com/pages/functions/pricing/)
10. [Routing (Pages Functions), Cloudflare Docs](https://developers.cloudflare.com/pages/functions/routing/)

## Verwandte Begriffe und Leistungen

Wichtige Begriffe: [Middleware](https://www.kondevs.com/de/glossary/#middleware), [KI-Agent](https://www.kondevs.com/de/glossary/#ai-agent), [IBM webMethods](https://www.kondevs.com/de/glossary/#webmethods), [Camunda](https://www.kondevs.com/de/glossary/#camunda-bpm)

Unsere Leistung: [Enterprise Integration & BPM](https://www.kondevs.com/de/services/eai-integration/)

cloudflare-workers edge-computing serverless-architektur ddos-schutz website-architektur