Wie du Cloudflare Workers als schlankes API-Gateway vor deine Automationen setzt: Routing am Edge, Zustand in KV und Queues, Auth und Rate-Limiting, und welche Subrequest- und Laufzeit-Limits dir Grenzen setzen.
Was ein Worker als Gateway leistet
Cloudflare Workers sind kleine Funktionen, die in Cloudflares Netz an vielen Standorten laufen, nah am Aufrufer und ohne dass du einen Server betreibst. Als API-Gateway sitzt ein Worker vor deinen eigentlichen Automationen und Diensten und übernimmt die Aufgaben, die sonst jede Automation einzeln lösen müsste: er nimmt Anfragen an, prüft die Berechtigung, leitet sie an das richtige Ziel weiter und drosselt bei Bedarf.
Der Reiz liegt darin, dass diese Schicht zentral und an einer Stelle wartbar ist. Statt in fünf n8n-Workflows fünfmal denselben Auth-Check zu pflegen, machst du ihn einmal im Worker. Die Automationen dahinter bleiben schlank und müssen sich nicht mit Authentifizierung und Missbrauchsschutz beschäftigen.
Routing am Edge
Das Kernstück ist das Routing. Der Worker liest Pfad, Methode und Header der eingehenden Anfrage und entscheidet, wohin sie geht. Ein /webhook/lead landet bei der Lead-Pipeline, ein /api/status bei einem anderen Dienst, alles andere bekommt einen 404. Diese Logik ist gewöhnlicher Code, kein Konfigurationsdialog, und damit versionierbar und testbar.
Weil der Worker am Edge läuft, passiert diese Entscheidung nah am Aufrufer, bevor die Anfrage überhaupt deinen eigentlichen Backend-Standort erreicht. Ungültige oder unberechtigte Anfragen wehrst du ab, bevor sie Last erzeugen. Das ist der Unterschied zu einem Gateway, das erst auf deinem zentralen Server prüft: hier wird der Müll schon an der Peripherie aussortiert.
Zustand mit KV und Queues
Workers selbst sind zustandslos, jede Anfrage startet frisch. Für Zustand gibt es eigene Bausteine. KV ist ein verteilter Schlüssel-Wert-Speicher, schnell im Lesen und über das ganze Netz repliziert. Er eignet sich für Dinge, die sich selten ändern und oft gelesen werden: API-Tokens, Feature-Flags, kleine Konfigurationen. Wichtig ist, dass KV erst nach kurzer Verzögerung überall konsistent ist, für Zähler oder kritische Sofort-Konsistenz ist es das falsche Werkzeug.
Queues lösen ein anderes Problem. Wenn ein eingehender Webhook eine längere Verarbeitung auslöst, willst du den Aufrufer nicht warten lassen. Der Worker legt die Aufgabe in eine Queue und antwortet sofort, ein Consumer arbeitet sie unabhängig ab. Das entkoppelt Annahme und Verarbeitung und fängt Lastspitzen ab, ohne dass etwas verloren geht. Diese Trennung ist oft der Unterschied zwischen einer Pipeline, die unter Last hält, und einer, die Timeouts wirft.
Authentifizierung an der Tür
Das Gateway ist der natürliche Ort für Authentifizierung. Der Worker prüft, bevor er irgendetwas weiterleitet, ob die Anfrage berechtigt ist. Für Maschine-zu-Maschine genügt oft ein geheimer Schlüssel im Header, den du gegen ein in Cloudflare hinterlegtes Secret prüfst. Für signierte Webhooks, etwa von einem Zahlungsanbieter, verifizierst du die Signatur, bevor du den Inhalt überhaupt anfasst.
Entscheidend ist, Secrets als verschlüsselte Worker-Secrets zu hinterlegen und nicht in den Code zu schreiben. Eine ungültige Anfrage bekommt einen 401 und kommt keinen Schritt weiter. So bleibt die Auth-Logik an einer Stelle, und keine der dahinterliegenden Automationen muss ihr vertrauen oder sie wiederholen. Genau so verdrahten wir den Zugang zu unseren API-Pipelines.
Rate-Limiting gegen Missbrauch
Ein offener Webhook-Endpunkt ohne Drosselung ist eine Einladung. Rate-Limiting begrenzt, wie viele Anfragen ein Aufrufer in einem Zeitfenster machen darf. Cloudflare bietet dafür eine eigene Rate-Limiting-Funktion, und für feinere Logik kannst du Zähler in KV oder einem Durable Object führen und bei Überschreitung mit einem 429 ablehnen.
Der Zweck ist doppelt. Erstens schützt es deine dahinterliegenden Dienste und APIs vor Überlastung und vor dem Verbrennen von Kontingenten, etwa wenn dein Worker selbst eine kostenpflichtige API aufruft. Zweitens dämmt es Missbrauch ein, bevor er teuer wird. Ein Gateway ohne Rate-Limiting ist nur ein halbes Gateway. Diese Schutzschicht gehört für uns zum Standard in Ops-Automation.
Die Limits, die du einplanen musst
Workers sind schnell und günstig, aber nicht unbegrenzt. Das wichtigste Limit für ein Gateway ist die Zahl der Subrequests: ein Worker darf pro Anfrage nur eine begrenzte Anzahl ausgehender Requests machen, im kostenlosen Plan deutlich weniger als im bezahlten. Wer in einer Schleife viele Drittanbieter-APIs aufruft, stößt daran. Der Ausweg ist, Aufrufe zu bündeln oder die Arbeit über eine Queue an einen Consumer auszulagern.
Dazu kommen Grenzen bei CPU-Zeit pro Anfrage und bei der Speichermenge. Workers sind für kurze, schnelle Verarbeitung gebaut, nicht für langlaufende Rechenjobs. Wer das missachtet, bekommt abgebrochene Anfragen. Die ehrliche Einordnung: ein Worker ist ein hervorragendes Gateway und ein schlechter Ort für schwere Verarbeitung. Die gehört dahinter, in n8n, einen Queue-Consumer oder einen eigenen Dienst, mit einer Datenbank wie Supabase für den Zustand. Wie wir die Schichten für deinen Fall schneiden, besprechen wir über Kontakt.