Cloudflare Workers Edge in Berlin

#Warum Edge-Computing zur Berliner Wachstumslogik passt

Berliner Digitalunternehmen planen selten für den Bestand, sie planen für die nächste Stufe. Ein Produkt startet mit ein paar hundert Nutzern in Kreuzberg, sechs Monate später hängen Kunden aus London, Warschau und São Paulo an derselben Plattform, und die nächste Finanzierungsrunde setzt voraus, dass die Technik dieses Wachstum aushält, ohne dass parallel ein Infrastruktur-Team aufgebaut wird. Genau in diese Lücke passt Edge-Computing: Rechenleistung, die weltweit dort bereitsteht, wo die Nutzer sind, ohne dass jemand Server bestellt, Container orchestriert oder nachts Kapazitäten nachzieht.

Cloudflare Workers sind der handfeste Teil dieses Versprechens. Ein Worker ist Programmcode, der in den weltweit verteilten Rechenzentren von Cloudflare läuft, darunter ein Standort in Berlin selbst. Der Code startet in V8-Isolates ohne Kaltstart-Wartezeiten klassischer Serverless-Funktionen und skaliert vom ersten Nutzer bis zur Kampagnenspitze automatisch. Für ein Unternehmen, das seinen Ingenieuren lieber Produktarbeit als Serverpflege bezahlt, ist das keine Bequemlichkeit, sondern eine Personalentscheidung: Die Edge-Schicht ersetzt die DevOps-Stelle, die in Berlin ohnehin schwer zu besetzen und teuer zu halten ist.

Wir kennen diese Rechnung aus eigener Produktion: Hinter unserer eigenen, komplett über das Cloudflare-Netz ausgelieferten Plattform sitzt keine einzige Infrastruktur-Stelle. Was wir Berliner Kunden vorschlagen, betreiben wir selbst unter Last, und die Details der Leistung stehen auf der Übersichtsseite zur Cloudflare-Edge-Entwicklung.

#Internationale Nutzer ab Tag eins, aber nur ein Origin

Die meisten Berliner Digitalprodukte sind von Anfang an zweisprachig gedacht und international ausgerichtet. Die Website läuft auf Englisch und Deutsch, das Marketing zielt auf Europa oder gleich auf mehrere Kontinente, und die Nutzerbasis verteilt sich entsprechend. Die Infrastruktur dahinter erzählt oft eine andere Geschichte: ein einzelner Hosting-Server in einem deutschen Rechenzentrum, der jede Anfrage aus Lissabon, Helsinki oder New York über die volle Distanz beantwortet.

Diese Asymmetrie ist das eigentliche Latenzproblem, nicht die Millisekunden innerhalb Deutschlands. Eine Anfrage aus der US-Ostküste zu einem Server in Deutschland und zurück kostet allein durch die Signallaufzeit einen dreistelligen Millisekundenwert, bevor der Server überhaupt zu arbeiten beginnt. Eine typische Produktseite löst Dutzende solcher Anfragen aus. Wer internationale Conversion-Raten mit einer Ein-Origin-Architektur erklärt bekommen möchte, findet in den Web-Analytics meist deutliche Spuren: Absprungraten, die mit der Entfernung zum Rechenzentrum wachsen.

Eine Workers-Schicht dreht das Modell um. Vollständige HTML-Antworten, Bilder und Assets liegen an den weltweit verteilten Cloudflare-Standorten bereit, und der Nutzer in Toronto bekommt seine Antwort aus einem nordamerikanischen Rechenzentrum statt aus Deutschland. Der Origin in Deutschland bleibt die einzige Quelle der Wahrheit, wird aber nur noch für das gebraucht, was wirklich dynamisch ist: eingeloggte Sitzungen, Warenkörbe, Checkout. Für Core Web Vitals wirkt das direkt auf Time to First Byte und damit auf Largest Contentful Paint, gemessen mit realen Nutzerdaten aus allen Märkten, nicht nur aus dem deutschen.

#Workers als Vorbau, WordPress als Maschinenraum

Ein Punkt, der in Berliner Erstgesprächen oft überrascht: Für eine Edge-Architektur muss niemand WordPress verlassen. Das Redaktionssystem, der WooCommerce-Checkout, die gewachsene Plugin-Landschaft, all das bleibt unangetastet im Maschinenraum. Die Workers-Schicht ist ein Vorbau davor, der die Aufgaben übernimmt, für die ein PHP-Server strukturell der falsche Ort ist.

Dazu gehört das Zwischenspeichern vollständiger Seiten mit sitzungsgenauer Unterscheidung: Anonyme Besucher erhalten die gecachte Antwort in zweistelliger Millisekundenzeit, eingeloggte Nutzer und gefüllte Warenkörbe werden am Cache vorbei zum Origin geleitet. Dazu gehören Weiterleitungen in Größenordnungen, an denen .htaccess-Dateien und Plugin-Lösungen scheitern, zentral gepflegte Security-Header, Geo-Routing für mehrsprachige Auftritte und A/B-Tests, die am Netzwerkrand entschieden werden statt per flackerndem JavaScript im Browser.

Die Arbeitsteilung hat einen Nebeneffekt, der in Sicherheitsdiskussionen zählt: Der Origin-Server ist für die Außenwelt nicht mehr direkt sichtbar. Angriffe, Scanner und Exploit-Versuche treffen zuerst auf die Edge-Schicht, und was dort abgefangen wird, erreicht die WordPress-Installation nie. Wer parallel am Fundament arbeiten will, findet die passende Leistung bei der WordPress-Entwicklung in Berlin, denn eine Edge-Schicht vor einem ungepflegten System ist eine Fassade vor einem Rohbau.

#Launch-Tage, Messen und der Traffic, der nicht wiederkommt

Berlin hat einen eigenen Veranstaltungsrhythmus, der sich in Server-Logs abzeichnet. Ein Product Launch mit koordinierter Presse, ein Auftritt zur IFA, ein Panel auf der re:publica, eine virale Runde auf Social Media: Der Traffic vervielfacht sich innerhalb von Minuten, hält Stunden oder Tage und fällt danach auf das alte Niveau zurück. Für die Infrastrukturplanung ist das die unangenehmste Lastkurve überhaupt, denn wer den Hosting-Vertrag auf die Spitze auslegt, bezahlt an 350 Tagen im Jahr für Leerlauf, und wer es nicht tut, erlebt den wichtigsten Tag des Quartals mit einer weißen Fehlerseite.

Die Edge-Antwort auf dieses Muster ist unspektakulär und wirksam: Die Besucherspitze besteht fast vollständig aus anonymen Erstbesuchern, und genau diese Anfragen lassen sich zu nahezu hundert Prozent am Netzwerkrand beantworten. Das Cloudflare-Netz trägt die Spitze, der Origin sieht nur die Handvoll Nutzer, die tatsächlich ein Konto anlegen oder bestellen. Der Hosting-Vertrag bleibt auf die Grundlast dimensioniert, und die Cache-Trefferquote pro Kampagne lässt sich im Dashboard nachlesen, was die Budgetdiskussion nach dem Launch deutlich verkürzt.

Wichtig ist der Vorlauf. Eine Edge-Schicht lässt sich nicht am Vorabend der Messe aufsetzen, wohl aber in den Wochen davor, inklusive Lasttest gegen das erwartete Szenario. Deshalb fragen wir im Audit zuerst nach Ihrem Kalender und erst danach nach Ihrer Technik.

#Scraping und Bots im dichtesten Wettbewerbsumfeld Deutschlands

Kaum eine deutsche Stadt hat pro Quadratkilometer mehr direkte Wettbewerber als Berlin zwischen Mitte, Kreuzberg und Friedrichshain. Wo mehrere Anbieter um dieselben Kunden konkurrieren, wird systematisches Auslesen von Preisen, Sortimenten und Inhalten zum Alltagsproblem: Scraper ziehen nachts die komplette Preisliste, KI-Crawler sammeln Inhalte für Trainingsdaten, und automatisierte Anfragen verzerren jede Analytics-Auswertung, auf deren Basis das Marketing entscheidet.

Die Größenordnung unterschätzt fast jeder, bis er die eigenen Server-Logs nach User-Agents und Anfragemustern filtert: Dort stehen regelmäßig mehr Maschinen als Menschen, und ein erheblicher Teil davon interessiert sich gezielt für Preise und Sortimente. Ein Worker setzt die Verteidigung dorthin, wo sie hingehört, nämlich vor den Server: Er klassifiziert automatisierten Traffic, drosselt Anfragen pro Netzwerksegment und unterscheidet erwünschte Crawler wie Googlebot von unerwünschten. Das Ergebnis ist dreifach: Die Preisliste bleibt schwerer abgreifbar, die Origin-Last sinkt, und die Analytics zeigen wieder Menschen statt Maschinen.

Ehrlicherweise gehört dazu: Einen entschlossenen Angreifer hält keine Filterlogik dauerhaft auf. Das Ziel ist, das Abgreifen so teuer und unzuverlässig zu machen, dass es sich für den Wettbewerber nicht mehr rechnet, und die eigene Infrastruktur von der Last zu befreien. Diese Erwartung setzen wir im Audit realistisch, bevor Code entsteht.

#DSGVO vor der strengsten Aufsicht des Landes

Die Berliner Beauftragte für Datenschutz und Informationsfreiheit hat in den vergangenen Jahren mehrfach bewiesen, dass sie Verstöße nicht nur anmahnt, sondern konsequent verfolgt, auch gegenüber großen Häusern. Wer in Berlin eine US-Cloud in seine Infrastruktur einbaut, sollte die Antwort auf die Datenschutzfrage nicht dem Zufall überlassen, und Investoren fragen in der Due Diligence inzwischen genauso danach wie die Aufsicht.

Die belastbare Antwort hat drei Schichten. Vertraglich schließt Cloudflare Auftragsverarbeitungsverträge nach Art. 28 DSGVO und legt seine Unterauftragsverarbeiter offen. Technisch begrenzt die Data Localization Suite die Verarbeitung von Anfrageinhalten auf EU-Standorte, einschließlich europäischer Schlüsselverwaltung. Architektonisch, und dieser Teil wird am häufigsten übersehen, entscheidet der Zuschnitt der Edge-Logik darüber, welche Daten überhaupt am Netzwerkrand ankommen: Ein Worker, der statische Seiten ausliefert und Bots filtert, verarbeitet strukturell weniger Personenbezug als einer, der Formulare oder Sitzungsdaten anfasst. Wir entwerfen die Datenflüsse so schmal wie möglich und liefern die Dokumentation für Ihr Verarbeitungsverzeichnis mit.

Zur ehrlichen Beratung gehört auch die Grenze: Wer vertraglich eine Verarbeitung ausschließlich auf deutschen Servern zusichern muss, für den ist eine global verteilte Edge-Plattform möglicherweise das falsche Werkzeug. Das klären wir vor dem Projekt, nicht danach.

#Drei Fallmuster aus Berliner Projekten

Anonymisiert, aber typisch für das, was zwischen Rosenthaler Platz und Oberbaumbrücke auf unseren Tischen landet.

Das Scale-up mit Launch-Spitzen: Ein Anbieter mit WooCommerce-Shop plante vierteljährliche Produkt-Launches mit Presse- und Newsletter-Begleitung. Jeder Launch legte den Shop für die erste halbe Stunde lahm, ausgerechnet dann, wenn die Aufmerksamkeit am größten war. Statt den Hosting-Vertrag zu verzehnfachen, fängt heute eine Edge-Cache-Schicht die anonymen Erstbesucher ab, ein Lasttest vor jedem Launch prüft das erwartete Szenario, und der Origin verarbeitet nur noch Warenkörbe und Checkouts. Seither entscheidet die Newsletter-Größe über den Umsatz, nicht über die Verfügbarkeit. Als das Scale-up nach der nächsten Runde den Markteintritt in Großbritannien vorzog, war die technische Vorbereitung ein Konfigurationsschritt statt eines Umbaus, weil die Auslieferung ohnehin bereits global aus dem Cloudflare-Netz lief und die britischen Nutzer vom ersten Tag an aus einem Rechenzentrum in ihrer Nähe bedient wurden.

Der Marktplatz mit Scraping-Problem: Eine Plattform mit tausenden Angeboten stellte fest, dass ein Wettbewerber Preise und Beschreibungen systematisch spiegelte, erkennbar an nächtlichen Traffic-Mustern und wortgleichen Inhalten auf fremder Domain. Ein Worker mit Bot-Klassifizierung und Ratenbegrenzung pro Netzwerksegment ließ legitime Suchmaschinen passieren und den Rest ins Leere laufen. Die Origin-Last sank spürbar, und die Marketing-Auswertungen zeigten erstmals seit Monaten belastbare Zahlen.

Die Agentur mit Multisite-Wildwuchs: Eine Berliner Agentur betrieb dutzende Kundenauftritte auf einer WordPress-Multisite, jeder mit eigenem Cache-Plugin, eigenen Weiterleitungen und eigener Header-Konfiguration. Eine zentrale Workers-Schicht ersetzte den Wildwuchs durch eine versionierte Edge-Konfiguration pro Hostname, mit Code-Review statt Klick-Konfiguration. Die Agentur pflegt seither eine Logik statt dreißig, und neue Kundenprojekte erben die Standards automatisch.

#Wann Edge-Computing die falsche Antwort ist

Nicht jedes Berliner Projekt braucht diese Architektur, und es wäre unseriös, das zu behaupten. Eine Kanzlei-Website mit regionaler Mandantschaft, ein Restaurant in Prenzlauer Berg, ein Portfolio mit ein paar hundert Besuchern im Monat: Dort erreicht ein solides Hosting mit gutem Cache-Plugin fast denselben Effekt für einen Bruchteil des Aufwands. Auch ein Frühphasen-Startup, das sein Produkt noch sucht, investiert seine Ressourcen besser in Produktarbeit als in Infrastruktur, die für eine Nutzerbasis gebaut ist, die es noch nicht gibt.

Ob sich ein Workers-Projekt lohnt, entscheiden im Berliner Kontext meist zwei Fragen. Die erste: Woher kommen Ihre Nutzer? Lautet die Antwort Charlottenburg statt Chicago, und soll das so bleiben, erledigt ein gutes Cache-Plugin den Job. Die zweite: Was passiert an Ihrem stärksten Tag? Ist der stärkste Tag ein gewöhnlicher Dienstag, gibt es keine Spitze, die eine Edge-Schicht abfangen müsste. Erst wenn internationale Nutzer, ein Launch-Kalender oder nächtliche Scraper in den Logs auftauchen, wird aus der Architektur eine Investition mit messbarer Rendite. Fällt diese Rechnung im Audit negativ aus, sagen wir das, und Sie sparen sich ein Projekt, das in der Wartung mehr kostet als es bringt.

#Ablauf: in Etappen zum belastbaren Ergebnis

Ein Worker, der vom ersten Tag an alles können soll, ist am Launch-Tag der riskanteste Code im gesamten Stack, deshalb bauen wir die Edge-Schicht in überschaubaren Schritten auf. Am Anfang steht eine Bestandsaufnahme mit Zahlen: TTFB aus realen Nutzerdaten nach Regionen, Cache-Verhalten, Bot-Anteil, dazu Ihr Kalender mit Launch- und Kampagnenterminen und die Datenschutzanforderungen. Am Ende dieser Messung steht eine Rangfolge: welche Route zuerst an den Netzwerkrand wandert und welcher Effekt sich dafür nachweisen lassen muss.

Der Einstieg in die Produktion ist absichtlich schmal geschnitten, etwa Caching und Bot-Filterung für die umsatzrelevanten Routen, und liefert innerhalb weniger Wochen Vorher-Nachher-Messwerte. Steht ein Launch bevor, folgt ein Lasttest gegen das erwartete Spitzenszenario, bevor die Erweiterung auf weitere Routen beginnt. Jede Etappe hat Regressionstests und einen dokumentierten Rückweg. Zum Abschluss übergeben wir eine Auslieferungskette per Git, Dashboards, Alarme und eine Dokumentation auf Deutsch oder Englisch, damit Ihr Team den Betrieb selbst trägt, statt dauerhaft von uns abzuhängen. Die Preisgestaltung ist individuell und folgt dem Umfang der Edge-Logik, die Cloudflare-Plattformkosten sind davon getrennt und öffentlich einsehbar.

#Beide Welten unter einem Dach

Ein Edge-Projekt vor einem WordPress-System hat zwei Hälften, die sich gegenseitig kaputtmachen können. Eine Cache-Regel, die den Warenkorb-Cookie übersieht, zeigt Stammkunden den Warenkorb eines Fremden, und ein harmloses Plugin-Update am Origin kann eine Edge-Annahme still entwerten, ohne dass ein Test anschlägt. Solche Fehler entstehen genau an der Naht zwischen zwei Dienstleistern, von denen jeder nur seine Hälfte kennt. Deshalb halten wir beide Hälften in einer Hand: dieselbe Auslieferungskette, dieselbe Cache-Invalidierung und dasselbe Monitoring für Worker und WordPress, mit Erfahrungswerten aus eigener Produktion statt aus Zertifikatskursen.

Für Shops ist die WooCommerce-Entwicklung in Berlin der natürliche Einstieg in die Zusammenarbeit, und wer über die Edge-Schicht hinaus über ein statisches Frontend nachdenkt, findet die Abwägung im Leitfaden zur Migration auf Next.js oder Astro. Der Anfang ist in jedem Fall derselbe: Wir messen, bevor wir empfehlen. Fällt die Rechnung gegen die Edge-Schicht aus, sagen wir das genauso deutlich, dann bleibt Ihr Budget im Produkt, wo es in dieser Phase mehr bewirkt.

Für Berliner SaaS-Teams und Kreativagenturen gehört zur Übergabe außerdem eine klare Zuständigkeitsmatrix. Sie hält fest, wer Cache-Regeln freigibt, wer bei einem Alarm entscheidet und welche Änderung zuerst am Origin oder am Worker geprüft wird. Das ist besonders wertvoll, wenn Produkt, Marketing und externe Entwicklung gemeinsam veröffentlichen. Ein kleines Runbook verhindert dann, dass ein Kampagnenproblem zwischen mehreren Teams liegen bleibt. Wir liefern diese Betriebslogik zusammen mit dem Code und testen den Rückweg einmal praktisch, bevor das Projekt als abgeschlossen gilt.

Zuletzt aktualisiert: 10. Juli 2026