Cloudflare Workers Pricing: Previews im Kostencheck

Beim Thema Cloudflare Workers Pricing lautet die kurze Antwort auf die Frage nach kostenlosen Worker Previews: Ja. Workers Free umfasst 100 Previews pro Worker und 100 Deployments pro Preview. Branch-Tests werden dadurch allerdings nicht unbegrenzt kostenlos; dynamische Ausführung, Build-Minuten, Speicher, KI-Inferenz und Containers unterliegen weiterhin eigenen Limits oder Preisen.

Cloudflare Worker Previews stellt für jeden Git-Branch eine produktionsnahe Umgebung unter demselben Worker bereit. Entscheidend ist deshalb nicht allein der Preis von "$0". Das Preview-Objekt gehört zum Free-Tarif, doch der Branch nutzt zugleich dieselben Plattformprodukte, die ohnehin in die Kostenplanung einfließen müssen.

Sind Cloudflare Worker Previews kostenlos?

Ja, das Preview-Kontingent ist kostenlos. Die aktuellen Preview-Limits von Cloudflare sehen im Free-Tarif 100 Previews pro Worker vor, in kostenpflichtigen Tarifen 500. In beiden Fällen kann jedes Preview 100 Deployments enthalten.

Diese Antwort hat jedoch eine klare Grenze. Ein Preview ist ein Umgebungsobjekt, kein Paket aus kostenloser Laufzeit, Speicher, Builds oder Modellaufrufen. Laut der aktuellen Workers-Preisseite erhalten Free-Konten weiterhin 100,000 dynamische Worker-Anfragen pro Tag bei einem CPU-Limit von 10 Millisekunden je Aufruf. Workers Paid beginnt weiterhin bei $5 pro Konto und Monat, enthält monatlich 10 Millionen Anfragen sowie 30 Millionen CPU-Millisekunden und berechnet anschließend die veröffentlichten Mehrverbrauchspreise.

Die aktuellen Preview- und Preisunterlagen wurden am 28. September 2026 geprüft. Auf keiner der beiden Seiten wird ein eigener Preview-Preis genannt. Ebenso wenig versprechen sie unbegrenzte Preview-Ausführung oder ein separates Nutzungskontingent. Für eine belastbare Kalkulation gilt daher: kostenloses Preview-Kontingent, bestehende Produktzähler.

Was sich am 22. September 2026 geändert hat

Cloudflare hat Worker Previews am 22. September 2026 eingeführt. Seitdem erhält jeder Branch eine eigene laufende Umgebung mit stabiler Preview-URL, Konfiguration, Observability und eigenem Zustand. Mit npx wrangler preview wird das Preview des aktuellen Branches erstellt oder aktualisiert.

Für Unternehmen verkürzt sich damit die Schleife vom Code bis zum belastbaren Nachweis. Ein Coding-Agent kann einen Branch deployen, Anfragen senden, Logs und Traces prüfen, den Code überarbeiten und anschließend dieselbe teilbare Preview-URL aktualisieren – noch bevor etwas in die Produktion gemergt wird. Mehrere Agents oder Entwickler können parallel arbeiten, ohne sich bei einem gemeinsamen Staging-Worker abzuwechseln.

Jeder Branch erhält zwei nützliche URL-Typen. Die Preview-URL verweist stets auf das neueste Deployment des Branches. Eine Deployment-URL bleibt dagegen an genau ein Deployment gebunden. Dadurch lassen sich Review-Kommentare und Regressionsvergleiche reproduzieren.

Die Trennung geht über die URL hinaus. Cloudflare legt für jedes Preview automatisch einen eigenen Durable-Object-Namespace samt Speicher an. Außerdem können eine separate Container-App und eigene Instanzen bereitgestellt werden. Variablen, Secrets und Bindings dürfen von der Produktionskonfiguration abweichen; Logs und Traces bleiben auf den Branch begrenzt.

Das ist ein leistungsfähigerer Workflow als das frühere Modell mit Version URLs, aber noch keine vollständige Kopie der Produktion. Mehrere Bindings und Trigger greifen weiterhin auf gemeinsame oder produktive Systeme zu. Wie viele Berechtigungen ein Agent erhält, sollte sich an dieser Einschränkung orientieren – nicht am Komfort der Preview-URL.

Cloudflare Workers Free: Was der kostenlose Tarif umfasst

Für einen üblichen Branch-Workflow ist der Free-Tarif großzügig bemessen. Ein Worker kann 100 Preview-Umgebungen enthalten, und jedes Preview bewahrt 100 Deployments auf. Paid erhöht die Zahl der Umgebungen auf 500, nicht jedoch den Deployment-Verlauf pro Preview.

Dabei handelt es sich um verschiedene Dimensionen. Wird ein Branch wiederholt deployt, belegt er weiterhin nur einen Preview-Platz, während sein Deployment-Verlauf wächst. Mehrere Branches mit jeweils einem aktiven Preview belegen mehrere Preview-Plätze – selbst dann, wenn keiner davon Traffic erhält.

Ein Vergleich der alten und neuen Objektlogik macht den Unterschied deutlich. Um fünf Branches mit Wrangler-Umgebungen abzubilden, mussten fünf getrennte Workers verwaltet werden. Worker Previews bündelt dieselbe Anzahl von Branches unter einem Worker in Form von fünf Preview-Objekten. Im Free-Tarif sinkt die Kontobelegung dadurch von 5% des Limits von 100 Workers auf 1% des Worker-Limits plus 5% des Preview-Kontingents dieses Workers. Der dokumentierte Grundpreis kann in beiden Varianten bei $0 bleiben, solange die Nutzung innerhalb der Limits liegt. Der Vorteil besteht in einfacherer Isolation und weniger Umgebungswildwuchs, nicht in günstigerer Ausführung.

Worker Previews setzt Wrangler 4.135.0 oder neuer voraus. Maßgeblich ist die projektlokale Version, denn Projektbefehle ersetzen eine ältere lokale Installation nicht stillschweigend durch eine neuere globale Version. In älteren Repositories kann das leicht zu der falschen Diagnose führen, das Feature sei nicht verfügbar.

Auch die Konfigurationsgrenze ist wichtig. Previews übernehmen die Produktionseinstellungen nicht. Ein Branch erhält die Angaben aus dem previews-Block sowie die Ressourcen, die Cloudflare automatisch isoliert. Ist der Block leer oder unvollständig, kann das Deployment erfolgreich sein, obwohl das Preview die vom Code erwartete Ressource nicht erreicht.

Cloudflare Workers Limits: Was zuerst gelöscht wird

Sobald eines der Objektlimits erreicht ist, räumt Cloudflare automatisch auf. Auf Worker-Ebene wird das Preview gelöscht, dessen letztes Deployment am weitesten zurückliegt. Innerhalb eines Previews verschwindet das älteste Deployment.

Das 101. Deployment desselben Previews löst damit eine Aufbewahrungsaktion aus: Das älteste Deployment wird entfernt, damit das neue Platz findet. Daraus folgt nicht, dass die ersten 100 Builds kostenlos waren. Workers Builds erfasst Build-Minuten separat – unabhängig davon, ob daraus Produktions- oder Preview-Deployments entstanden sind.

Für einen Agent, der einen Branch häufig überarbeitet, bleibt die stabile Preview-URL nützlich, weil sie immer auf das neueste Deployment zeigt. Das Risiko liegt im forensischen Verlauf. Muss ein Team einen älteren Fehler reproduzieren, sollte es die betreffende Deployment-URL und die Logs sichern, bevor dieses Deployment zum ältesten Eintrag wird.

Auch die automatische Objektlöschung ersetzt keine vollständige Richtlinie zur Ressourcenbereinigung. Wird ein Preview gelöscht, entfernt Cloudflare dessen Preview-Datensatz und Durable-Object-Namespace. Cloudflare weist jedoch darauf hin, dass eine generierte Container-App sichtbar bleiben kann. Ein Job für geschlossene Branches sollte deshalb zuerst das Preview löschen und anschließend die Container-Anwendungen prüfen, sofern Containers eingesetzt wurden.

Cloudflare Workers Pricing: vier Kostenebenen

Beim Cloudflare Workers Pricing gibt es keinen veröffentlichten Einzelpreis pro Preview. Praktisch setzt sich die Rechnung weiterhin aus vier Ebenen zusammen: Worker-Ausführung, Builds, gebundene Ressourcen sowie optionale Rechen- oder Modellprodukte.

1. Worker-Ausführung

Workers Free erlaubt pro Konto 100,000 Anfragen am Tag und begrenzt jeden Aufruf auf 10 Millisekunden CPU-Zeit. Anfragen an statische Assets sind kostenlos und unbegrenzt; das Anfragekontingent gilt für Zugriffe, die Worker-Code ausführen. Ein Branch-Test, der nur statische Dateien lädt, kann daher sehr günstig wirken, während ein API-lastiger Test das dynamische Kontingent verbraucht.

Workers Paid beginnt bei $5 pro Konto und Monat. Enthalten sind monatlich 10 Millionen Anfragen und 30 Millionen CPU-Millisekunden. Danach kosten eine weitere Million Anfragen $0.30 und eine weitere Million CPU-Millisekunden $0.02. Für HTTP-Aufrufe gilt bei Paid standardmäßig ein CPU-Limit von 30 Sekunden, das sich auf bis zu 5 Minuten erhöhen lässt.

Das Free-Limit von 10 Millisekunden ist oft die erste Hürde. Mehr Anfragevolumen gleicht es nicht aus. Selbst eine Test-Suite mit nur wenigen Anfragen scheitert, wenn ein dynamischer Aufruf regelmäßig mehr als 10 Millisekunden CPU-Zeit benötigt.

Für die übergeordnete Plattformentscheidung trennt der Cloudflare-Test den Workers-Kontotarif für $5 von den an Domains gebundenen Anwendungstarifen und weiteren Produktzählern von Cloudflare.

2. Workers Builds

Laut Limits und Preisen von Workers Builds erhalten Free-Konten monatlich 3,000 Build-Minuten, einen gleichzeitigen Build und ein Timeout von 20 Minuten. Paid enthält 6,000 Minuten und berechnet danach $0.005 je weiterer Minute; sechs Builds können parallel laufen, das Timeout bleibt gleich. Von Agents erzeugte Branches können daher das Parallelitäts- oder Minutenlimit erreichen, obwohl nur wenige Preview-Objekte belegt sind.

Genau deshalb bedeutet „100 Deployments pro Preview“ nicht „100 enthaltene Builds“. Der eine Wert beschreibt den aufbewahrten Deployment-Verlauf, der andere die CI-Rechenleistung.

3. Speicher und gebundene Ressourcen

KV, D1, R2, Queues, Vectorize, Hyperdrive und andere Bindings verwenden eigene Ressourcenkennungen und Zähler. Sind zwei Previews mit derselben D1-Datenbank oder demselben R2-Bucket verbunden, teilen sie sich die Daten. Für Isolation ist eine separate Ressource nötig, die wiederum dem Preismodell des jeweiligen Produkts folgt.

Zur Einordnung: R2 enthält 10 GB-Monate, 1 Million Class-A-Operationen und 10 Millionen Class-B-Operationen pro Monat. Darüber hinaus kostet Standardspeicher $0.015 pro GB-Monat, Class A $4.50 pro Million und Class B $0.36 pro Million. D1 Free umfasst täglich 5 Millionen gelesene und 100,000 geschriebene Zeilen sowie insgesamt 5 GB Speicher. Die Analyse der D1-Free-Limits zeigt, warum eine gemeinsam genutzte Staging-Datenbank zur Verfügbarkeitsgrenze werden kann, obwohl weiterhin Preview-Objekte verfügbar sind.

KV besitzt ein weiteres, eigenständiges Tageskontingent: Im Free-Tarif sind es 100,000 Lesevorgänge, 1,000 Schreibvorgänge, 1,000 Löschvorgänge und 1,000 Listenabfragen bei 1 GB Speicher. Ein Test, der einen Namespace befüllt oder leert, kann dieses Kontingent deutlich schneller aufbrauchen als ein reiner Lesetest.

4. KI-Inferenz und Containers

Workers AI Pricing sieht sowohl für Free- als auch Paid-Konten täglich 10,000 Neurons ohne Berechnung vor. Bei Paid kostet die Nutzung oberhalb dieses Kontingents $0.011 pro 1,000 Neurons. Ein Branch-Test mit Modellaufruf muss folglich zwei Vorgänge einkalkulieren: die Worker-Anfrage und die dadurch ausgelöste Inferenz. Das Abonnement eines externen Coding-Agents oder eine Modell-API eines anderen Anbieters ist eine zusätzliche Rechnung und nicht im Preview-Kontingent enthalten.

Die Container-Preise führen für Free kein Container-Kontingent auf. Workers Paid umfasst monatlich 25 GiB-Stunden Arbeitsspeicher, 375 vCPU-Minuten und 200 GB-Stunden Festplattenspeicher; für Mehrverbrauch gelten separate Preise. Container-Traffic nutzt außerdem Workers und Durable Objects. Ein automatisch isolierter Preview-Container ist damit kein Produkt mit nur einem Zähler.

Kosten von Worker Previews für fünf aktive Branches

Ein sauberes Rechenblatt beginnt bei der Arbeitslast, nicht beim Tarifnamen. Angenommen, fünf aktive Branches erhalten jeweils 200 dynamische Testanfragen pro Tag. Über fünf Preview-Objekte hinweg sind das täglich 1,000 Anfragen.

Im Free-Tarif ist die Anzahl der Previews komfortabel und der modellierte Traffic gering. Dem Konto bleiben täglich 99,000 dynamische Anfragen – allerdings nur, wenn nichts anderes das Kontingent nutzt. Produktions-Traffic, andere Workers und alle fünf Branch-Umgebungen gehören gemeinsam in die Betriebsrechnung.

Dabei ist die Einordnung der Beleglage entscheidend. Cloudflare bezeichnet 100,000 Anfragen pro Tag als Limit des Kontotarifs, und ein Preview führt eine reale Version des Workers aus. Die Preview-Dokumentation sagt jedoch nicht ausdrücklich, dass Preview-Traffic denselben Zähler belastet. Bis eine Beobachtung der Kontonutzung oder eine eindeutige Aussage von Cloudflare dies bestätigt, ist die Anrechnung auf das gemeinsame Kontingent daher eine konservative Planungsannahme.

Für diese Prüfung standen weder Zugangsdaten zu einem Cloudflare-Konto noch ein Worker-Projekt oder eine projektlokale Wrangler-Installation zur Verfügung. Es wurden keine temporären Previews deployt und keine Nutzungsänderung gemessen. Das Preview-Kontingent ist anhand der Quellen bestätigt; dieses Rechenblatt bleibt ein Modell.

Bei Paid verursacht diese Branch-Arbeitslast allein keinen Anfrage-Mehrverbrauch, doch für das Konto fällt weiterhin der monatliche Mindestpreis von $5 an. CPU und angebundene Produkte können das Ergebnis verändern. Bei derselben Testdichte erzeugen alle 100 Free-Preview-Plätze 20,000 Anfragen pro Tag – 20% des modellierten Tageskontingents. Sämtliche 500 Paid-Plätze erzeugen in einem Monat mit 30 Tagen 3 Millionen Anfragen, also 30% des enthaltenen Monatskontingents. In beiden isolierten Beispielen wird das Preview-Objektlimit vor dem Anfragekontingent erreicht. Produktions-Traffic kann diese Reihenfolge umkehren.

Was das für Entwicklung, Betrieb und Einkauf bedeutet

Entwicklung erhält parallele Laufzeitnachweise, aber keine automatische Ressourcensicherheit

Jeder aktive Branch kann eine stabile URL und einen isolierten Durable-Object-Zustand erhalten. Damit entfällt der Konflikt einer gemeinsamen Staging-Umgebung, bei dem das Deployment eines Entwicklers den Review eines anderen ungültig macht. Auch ein Coding-Agent erhält so ein konkretes Ziel für curl, Browserprüfungen, Logs und Traces.

Die Grenze liegt in der Konfiguration. D1, KV und R2 werden nicht automatisch isoliert, nur weil der Code getrennt läuft. Verwenden zwei Previews dieselbe Kennung, teilen sie sich die Ressource. Als sicherer Standard empfiehlt sich eine eigene Nicht-Produktionsressource oder eine bewusst gemeinsam genutzte Staging-Ressource mit entbehrlichen Daten.

Der Betrieb verantwortet das gemeinsame Budget und die Bereinigung

Im Betrieb sollten vier Werte getrennt erfasst werden: aktive Preview-Objekte, aufbewahrte Deployments pro Preview, dynamische Worker-Nutzung und die Nutzung angebundener Produkte. Eine einzige Dashboard-Summe kann diese vier Größen nicht erklären.

Die Bereinigung gehört in die Pull-Request-Automatisierung. Wenn ein Branch geschlossen wird, sollte sein Preview gelöscht werden. Wurden Containers eingesetzt, ist anschließend die generierte Container-Anwendung zu prüfen. Benötigte Deployment-URLs oder Traces eines Vorfalls müssen gesichert werden, bevor die Aufbewahrungslogik sie entfernt.

Der Einkauf sollte für eine konkrete Grenze upgraden

Paid ist nicht allein deshalb nötig, weil „Preview“ nach einem Premium-Feature klingt. Ein Upgrade ist dann sinnvoll, wenn eine benannte Anforderung Free überschreitet: mehr als 100 gleichzeitige Previews für einen Worker, dynamischer Traffic samt Produktion nahe 100,000 Anfragen am Tag, ein Aufruf mit mehr als 10 Millisekunden CPU-Zeit oder irgendeine Container-Anforderung.

Paid kann auch schon vor Erreichen des reinen Volumenlimits die vernünftige Risikoentscheidung sein. Ein Team mit Kundenkontakt zieht möglicherweise ein Monatskontingent mit Mehrverbrauchsrechnung einem täglichen Free-Limit vor, obwohl fünf Branch-Tests lediglich 1% des modellierten Tageskontingents beanspruchen.

Was jetzt anders laufen sollte

Sofort handeln sollten Teams, in denen sich mehrere Entwickler oder Agents bei einem veränderlichen Staging-Worker abwechseln. Die Branch-Validierung gehört dann in Previews, ergänzt um eine Richtlinie für Nicht-Produktionsressourcen und eine CI-Bereinigung beim Schließen eines Branches. Das Feature beseitigt direkt einen Koordinationsengpass.

Abwarten ist sinnvoll, wenn die Anwendung von Multi-Worker-Service-Bindings, Queue-Consumern, Cron Triggers, Produktionsrouten oder automatisch isolierten Workflows abhängt. Diese Pfade bleiben derzeit nicht vollständig innerhalb eines Previews. Zwar lässt sich der HTTP-seitige Ausschnitt testen, doch die Isolation des Gesamtsystems kann ein Preview nicht belegen.

Weitgehend ohne Auswirkung bleibt die Neuerung für Projekte, die bereits anderswo eine stabile Umgebung pro Branch nutzen oder deren Worker statisch ist und deren Änderungen vollständig durch lokale Prüfungen und Deployment-Versionen abgedeckt sind. Ein neues Objekt schafft nicht allein dadurch Nutzen, dass es existiert.

Die Entscheidungsregel ist eindeutig: Free passt, solange Objektanzahl, CPU-Zeit je Aufruf, modellierter Kontotraffic und Produktanforderungen innerhalb ihrer Grenzen bleiben. Sobald eine dieser Grenzen betrieblich relevant wird, ist Paid angebracht. Die Zahl der Anfragen ist nicht der einzige Umschlagpunkt.

Was übertrieben dargestellt wird

Am überzeugendsten ist die Ankündigung dort, wo sie einen isolierten Branch-Worker beschreibt. Als isolierte Kopie einer vollständigen Cloudflare-Anwendung verstanden, geht sie zu weit.

• Ein Service Binding aus einem Preview ruft das Produktions-Deployment des anderen Workers auf. Multi-Worker-Anfragepfade werden nicht automatisch Branch für Branch zugeordnet.
• Ein Workflow Binding verwendet einen bestehenden deployten Workflow. Cloudflare legt für den Branch keinen Preview-spezifischen Workflow an.
• Ein Preview kann Nachrichten an eine Queue senden, aber nicht als Queue-Consumer arbeiten. Zeigt es auf eine Produktions-Queue, kann die Produktion seine Testnachrichten verarbeiten.
• Cron Triggers und Produktionsrouten bleiben auf die Produktion gerichtet.
• KV, D1, R2 und mehrere weitere Ressourcen sind nur dann isoliert, wenn eine andere Ressourcenkennung gebunden wird.
• Preview-URLs sind standardmäßig öffentlich. Die workers.dev-Variante enthält X-Robots-Tag: noindex; ein Preview auf einer eigenen Domain sollte jedoch mit Cloudflare Access geschützt werden, wenn unveröffentlichte Arbeit vertraulich bleiben muss.
• Container-Unterstützung ist nur teilweise vorhanden, und nach dem Löschen kann die generierte App sichtbar bleiben, bis sie separat bereinigt wird.

Für einen Agent sind das keine Randfälle. Genau diese Unterschiede entscheiden, ob „der Agent seinen Branch testen kann“ oder „der Agent die Produktion nicht berühren kann“. Die aktuelle Matrix zur Ressourcenisolation sollte deshalb als Berechtigungsdokument behandelt werden, nicht als optionale Einrichtungslektüre.

Auch die finanzielle Lesart wird schnell überzogen: 100 Previews im Free-Tarif bedeuten nicht 100 vollständig kostenlose Staging-Stacks. Cloudflare erlaubt damit einem Worker lediglich, entsprechend viele Preview-Objekte zu halten. Das Budget bestimmen die dahinterliegenden Ressourcen.

Erst das Kontingent prüfen, dann den Einrichtungsleitfaden nutzen

Zur Prüfung des Kontingents genügen vier Fragen:

1. Läuft das Konto unter Workers Free oder Paid?
2. Wie viele aktive Previews besitzt dieser Worker bereits?
3. Welchen Anteil des Anfrage- und CPU-Budgets verbrauchen die Produktion und andere Workers bereits?
4. Ist im Projekt Wrangler 4.135.0 oder neuer festgelegt?

Wenn diese Antworten innerhalb der Grenzen liegen, führt der offizielle Einrichtungsleitfaden für Worker Previews durch Konfiguration und Deployment. Die Kostenprüfung sollte separat erfolgen: Jede gebundene Ressource, jeder Build-Pfad, jeder Modellaufruf und jeder Container muss erfasst sein, bevor ein Agent Branches erzeugt.

FAQ zu Cloudflare Worker Previews

Kann ich Cloudflare Workers kostenlos nutzen?

Ja. Workers Free kostet $0, enthält täglich 100,000 dynamische Worker-Anfragen und unterstützt bis zu 100 Previews pro Worker. Pro Aufruf gilt weiterhin ein CPU-Limit von 10 Millisekunden, und angebundene Produkte behalten ihre eigenen Kontingente.

Was kostet ein Cloudflare Worker?

Workers Free kostet $0. Workers Paid beginnt bei $5 pro Konto und Monat, umfasst 10 Millionen Anfragen sowie 30 Millionen CPU-Millisekunden und berechnet danach die veröffentlichten Mehrverbrauchspreise. Für ein Preview ist kein separater Grundpreis veröffentlicht.

Wie viele Cloudflare Workers kann ich kostenlos betreiben?

Workers Free erlaubt 100 Workers pro Konto. Davon zu unterscheiden ist das Worker-Previews-Limit: Im Free-Tarif sind unter jedem Worker 100 Previews möglich.

Was kostet Cloudflare Workers AI?

Workers AI enthält täglich 10,000 Neurons ohne Berechnung. Bei Workers Paid kostet die Nutzung oberhalb dieses Tageskontingents $0.011 pro 1,000 Neurons.

Ist Cloudflare Workers AI kostenlos?

Workers AI besitzt sowohl bei Workers Free als auch Workers Paid ein kostenloses Tageskontingent von 10,000 Neurons. Free-Konten stoppen an dieser Grenze; Paid-Konten können die Nutzung für $0.011 pro 1,000 Neurons darüber hinaus fortsetzen.

Wer ist der größte Wettbewerber von Cloudflare?

Für die Netzwerk-, Sicherheits-, Rechen-, Speicher- und Entwicklerprodukte von Cloudflare gibt es keinen einzelnen Wettbewerber. Sinnvoll ist der Vergleich der konkreten Schicht, die ersetzt werden soll, statt des gesamten Unternehmens als ein einziges Produkt.

Warum fällt Cloudflare?

Die Frage ist mehrdeutig und zeitabhängig: Gemeint sein könnten Aktienkurs, Dienststatus, Traffic oder eine andere Kennzahl. Keine dieser Auslegungen ändert die Limits von Worker Previews, die am 28. September 2026 anhand der aktuellen Cloudflare-Dokumentation geprüft wurden.

Ist Cloudflare ein russisches Unternehmen?

Nein. In der Unternehmensübersicht von Cloudflare wird San Francisco als Hauptsitz genannt; außerdem ist Cloudflare, Inc. demnach unter dem Kürzel NET an der New York Stock Exchange gelistet.

Warum nutzt das FBI Cloudflare?

Dieser Artikel belegt nicht, dass das FBI Cloudflare nutzt, und trifft keine Aussage über die Anbieterlandschaft einer Behörde. Die Frage hat keinen Bezug zum dokumentierten Kontingent und zu den Nutzungslimits von Worker Previews.

Der Schritt am Montag

Für den Einstieg eignen sich fünf Branches mit jeweils höchstens 200 dynamischen Testanfragen pro Tag. Die daraus entstehenden 1,000 täglichen Anfragen sollten im Budget als Annahme eines gemeinsamen Zählers gekennzeichnet werden. Sobald Zugriff auf die Abrechnung besteht, ist die Anfragenutzung des Kontos vor und nach dem Pilotprojekt festzuhalten. Bestätigt die Differenz das Modell, bleibt das Rechenblatt bestehen; andernfalls wird die Annahme durch die Beobachtung ersetzt.

Parallel dazu gehört jedes Binding im previews-Block in eine Bestandsaufnahme. Die Kennzeichnung lautet jeweils automatische Isolation, dedizierte Testressource, bewusst gemeinsam genutzt oder mit Produktionszugriff. Ein Agent sollte erst deployen dürfen, wenn für jede Zeile mit Produktionszugriff eine ausdrückliche Begründung vorliegt.

Soll das nächste Infrastruktur-Release ebenfalls in eine Budget- und Betriebsentscheidung übersetzt werden? Newsletter abonnieren.