Cloudflare Free-Tier: Limits für CDN, DNS, WAF und Workers im Überblick

Cloudflares Free-Tier gilt bei vielen Entwicklern als Segen: globales CDN, DDoS-Schutz, SSL-Zertifikate und DNS – alles kostenlos. Aber „kostenlos” hat immer Grenzen.

Workers: 100.000 Anfragen/Tag. Pages: 500 Builds/Monat. DNS: maximal 1.000 Einträge. Was bedeuten diese Zahlen? Wird Ihr Projekt plötzlich gedrosselt? Dieser Artikel listet alle Produktlimits und hilft bei der Einschätzung.

Kurz gesagt: Wenn Sie ein persönliches Blog oder kleines Projekt im Free-Tier hosten wollen, treffen Sie in 5 Minuten eine fundierte Entscheidung.

1. CDN und DNS: Hinter der „Unbegrenztheit”

Cloudflares stärkstes Argument: unbegrenzte Bandbreite. Viele Entwickler springen darauf an – aber nicht zu früh freuen.

Was bedeutet „unbegrenzt” beim CDN?

Die offizielle Dokumentation nennt keine Bandbreiten-Obergrenze – weder Free, Pro noch Business. Was folgt daraus?

Im Oktober 2024 teilte ein Reddit-Nutzer Messdaten: 20 TB Traffic/Monat, über Monate ohne Probleme. In der Cloudflare-Community berichten andere von 15 TB/Monat im Free-Tier – ebenfalls ohne Einschränkung.

Aber es gibt einen Haken. Die Terms of Service verbieten ausdrücklich: Streaming-Video und große Nicht-HTML-Dateien. Was „groß” ist? Keine feste Zahl. Cloudflare spricht von „unverhältnismäßiger Last” – vage, aber klar: Als Video-CDN nutzen führt früher oder später zu Sperrung.

Ein hartes Limit: 512 MB Cache pro Datei – in der Workers-Limits-Dokumentation für Free und Paid gleich. Große Videos cachen? Geht nicht.

Die „Unbegrenztheit” hat also zwei Ebenen:

1. Normaler Website-Traffic (HTML, CSS, JS, Bilder) – praktisch ohne Obergrenze
2. Video und Großdateien – ausdrücklich verboten

Blog, statische Site, kleiner API-Proxy? Unbedenklich. Bild-Hosting? OK, wenn einzelne Dateien unter 512 MB bleiben. Video-Plattform? Vergessen Sie es.

DNS-Einträge: oft übersehen

DNS ist Kernservice von Cloudflare – wo liegen Free-Limits?

September 2024 ist die Grenze: Zonen davor erlauben 3.000 Einträge, danach nur 1.000.

Warum? Keine offizielle Erklärung; die Community vermutet Missbrauchsschutz – Massenanlage von Domains mit Spam-Einträgen.

Reichen 1.000? Pro Domain mit Dutzenden Subdomains plus MX/TXT meist einige Hundert – ausreichend. Die eigentliche Frage: Wie viele Domains haben Sie?

Gute Nachricht: Kein Limit für die Domain-Anzahl. Free-Accounts können unbegrenzt Domains hinzufügen – solange jede Zone unter 1.000 Einträgen bleibt.

Detail: DNS-Abfragen selbst sind nicht limitiert. Hoher Traffic blockiert die Auflösung nicht.

Praxis: wann reicht es?

Ihr Projekt passt typischerweise, wenn es eines davon ist:

• Persönlicher Blog (WordPress, Hexo, Hugo) – vollständig ausreichend
• Statische Site (Astro, Next.js SSG) – vollständig ausreichend
• Kleiner API-Proxy (wenige Backend-Dienste) – grundsätzlich ausreichend
• Bild-Hosting (Einzeldatei < 512 MB) – ausreichend, Gesamtvolumen im Blick

Darüber hinaus: ToS vorab lesen. Nicht erst nach Sperrung merken, dass Sie die Grenze überschritten haben.

2. Workers und KV: Grenzen der Compute-Schicht

Workers ist Cloudflares Edge-Computing: JavaScript oder TypeScript an 200+ Knoten weltweit. Klingt ideal – doch Free-Limits sind enger als beim CDN.

Workers-Anfragen: 100.000/Tag

Offiziell: 100.000 Anfragen/Tag im Free-Tier, Reset um 00:00 UTC.

Beispiel – durchschnittlich 10 API-Aufrufe pro Nutzer/Tag:

• 100 Nutzer → 1.000 Anfragen/Tag → ~30.000/Monat → sicher
• 1.000 Nutzer → 10.000 Anfragen/Tag → ~300.000/Monat → Limit überschritten

Typische Workers-Einsätze:

• API Gateway (Weiterleitung ans Backend)
• SSR (Next.js, Remix)
• Formularverarbeitung (POST)
• JWT-Validierung (unautorisierte Anfragen blockieren)

Jede Anfrage zählt. Bei 1.000 Besuchern/Tag und 5 Workers-Aufrufen pro Besuch: 5.000 Anfragen/Tag – noch OK. Zehnfaches Wachstum? Monatslimit überschritten.

Kritisch: 30 ms CPU-Zeit/Anfrage (Limits-Dokumentation). Reicht für JSON-Parsing, Routing, JWT – nicht für Bildkompression, PDF-Generierung oder ML-Inferenz.

Weitere Limits: Skript 1 MB (komprimiert), 64 Umgebungsvariablen à max. 5 KB – für kleine Projekte meist genug.

KV: Quoten der Cache-Schicht

Workers KV ist Edge-Key-Value-Speicher. Im Februar 2026 erhöhte Cloudflare die Free-Kontingente:

• Reads: 100.000/Tag
• Writes: 1.000/Tag
• Speicher: 1 GB

1.000 Writes/Tag ist eng.

Viele Writes bei: Session-Cache, Access-Logs, Zähler. Jede Anfrage schreibt ein KV-Eintrag → bei 1.000 Anfragen/Tag ist das Kontingent voll.

Reads sind großzügiger – 100.000/Tag für kleine Read-Cache-Szenarien:

• Konfigurationscache (API-Keys, Feature Flags)
• Statische Daten (Produktlisten, Artikelverzeichnisse)
• User-Profile (read-heavy)

KV als Vektorspeicher für RAG? Ungeeignet – keine Vektor-Suche, enge Write-Limits. Vektoren: Cloudflare Vectorize (Paid) oder Pinecone, Milvus extern.

D1: Edge-SQLite

D1 ist Cloudflares SQLite an der Edge. Stand Mai 2026 (buildmvpfast-Zusammenfassung):

• Row Reads: 5.000.000/Tag
• Row Writes: 100.000/Tag
• Speicher: 5 GB

Reads großzügig; Writes höher als KV – D1 eignet sich eher für Persistenz als reiner Cache.

Typische Szenarien:

• Blog-Kommentare (read-heavy)
• User-Profile (seltene Updates)
• Kleines CMS (Artikel, Tags, Kategorien)

E-Commerce mit vielen Bestellungen/Tag? Writes können explodieren.

Reicht es? Abhängig vom Traffic-Modell

Produkt	Free-Kontingent/Tag	Einsatz
Workers	100.000 Anfragen	Kleine API, SSR
Workers CPU	30 ms/Anfrage	Einfache Logik
KV Read	100.000	Read-Cache
KV Write	1.000	Session-Cache (eng)
D1 Read	5.000.000 Zeilen	Abfragen
D1 Write	100.000 Zeilen	Schreibzugriffe

Unter ~1.000 Besuchern/Tag meist ausreichend. Ab 5.000: Workers-Quota überwachen – täglich Dashboard prüfen, nicht erst bei 403 reagieren.

3. Pages: engere Deploy-Limits als erwartet

Cloudflare Pages hostet statische Sites mit Git-Integration und globalem Deploy. Free-Limits sind konkreter als bei Workers.

Dateianzahl und Builds: harte Obergrenzen

Laut Pages-Limits-Dokumentation:

• 20.000 Dateien/Site
• 500 Builds/Monat
• 1 paralleler Build
• 25 MB pro Datei

20.000 klingt viel – aber Next.js oder Astro mit hunderten Artikeln plus Medien nähert sich schnell der Grenze.

Im Januar 2026: Paid-Limit auf 100.000 Dateien erhöht; Free bleibt bei 20.000. Ab ~500 Artikeln oder vielen Medien droht die Wand.

500 Builds/Monat ist oft entscheidender. Jeder Git-Push triggert einen Build (sofern nicht abgebrochen):

• 2 Änderungen/Tag → ~60/Monat → sicher
• 10 Änderungen/Tag → ~300/Monat → knapp
• CI/CD pro Commit → Limit in einer Woche möglich

Nur 1 paralleler Build: zweiter Push wartet. Solo ok, im Team blockierend.

Szenario-Analyse

Statischer Blog (Hexo, Hugo, Astro):

• Dateien: meist unter 5.000 → OK
• Builds: wenige pro Woche → OK
• Fazit: vollständig ausreichend

Mittlere Content-Site (500+ Artikel):

• Dateien: nahe 20.000 → Achtung
• Builds: häufige Updates → mögliche Überschreitung
• Fazit: überwachen, Paid-Upgrade planen

Kleine SPA (React, Vue):

• Dateien: Build oft < 1.000 → OK
• Builds: intensive Entwicklung → Risiko
• Fazit: Build-Frequenz steuern

Team-Projekt:

• Parallele Builds: Warteschlangen → Effizienzproblem
• Builds: schnell am Limit
• Fazit: Paid für parallele Builds

Warnsignale

Paid erwägen bei:

1. >15.000 Dateien – nah am Limit
2. >300 Builds/Monat – hohes Tempo
3. Team >3 Personen – Build-Blocking
4. >50 neue Artikel/Monat – schnelles Wachstum

Pro $20/Monat: 100.000 Dateien, parallele Builds – günstiger als Notfall-Upgrade nach Drosselung.

4. R2 und WAF: Free-Grenzen bei Speicher und Sicherheit

R2 ist Objektspeicher, WAF der Web Application Firewall. Ihre Free-Limits bestimmen, wie weit das Projekt reicht.

R2: null Egress, aber begrenzter Speicher

Hauptvorteil: keine Egress-Gebühren. AWS S3: ~$0,09/GB Egress; R2: $0.

Free-Limits laut Pricing:

• 10 GB Speicher
• Class A (Write/List): 1.000.000/Monat
• Class B (Read): 10.000.000/Monat

Was passt in 10 GB?

• Bilder (~500 KB) → ~20.000 Stück
• PDF (~5 MB) → ~2.000
• Video (~100 MB) → ~100

Bei unkontrollierten User-Uploads kann der Speicher in zwei Monaten voll sein.

Operations-Kontingente sind großzügiger. Read-lastige Bild-CDN-Szenarien selten problematisch; write-lastige Uploads überwachen.

WAF: begrenzt, aber für viele ausreichend

Free-WAF laut Dokumentation (Stand Mai 2026):

• Cloudflare Free Managed Ruleset (Teilmenge)
• Nur Domain-Level-WAF, kein Account-Level
• Kein WordPress-spezifischer Schutz
• Custom Firewall Rules verfügbar

„Teilmenge” bedeutet: Schutz vor kritischen Schwachstellen, nicht alle Regeln – u. a. OWASP Top 10, teilweise Cloudflare-Bedrohungsregeln, kritische CVEs.

Nicht enthalten:

• WordPress-spezifischer Schutz (ab Pro)
• Erweiterte Managed Rules
• Account-weites Regelmanagement

Custom Rules möglich:

• IP-Block
• Geo-Blocking
• User-Agent-Filter
• URL-Pfad-Schutz

Für Blogs und persönliche Projekte meist ausreichend. E-Commerce oder Finanzen: Paid mit vollem Ruleset empfohlen.

Szenario-Tabelle

Szenario	R2 ausreichend?	WAF ausreichend?
Persönlicher Blog (<100 Bilder)	✓ Ja	✓ Ja
Bild-Hosting (kontrollierte Uploads)	✓ Volumen beachten	✓ Ja
Bild-Hosting (unkontrolliert)	✗ Risiko	✓ Ja
Datei-Sharing (PDF/Docs)	✓ je nach Anzahl	✓ Ja
Kleiner Shop (keine sensiblen Daten)	✓ Ja	△ Upgrade erwägen
Mittlerer Shop (Zahlungsflow)	✓ Ja	✗ Upgrade empfohlen

10 GB R2 ist oft der Engpass. Bei unkontrollierten Uploads: früh skalieren oder AWS S3 / Backblaze B2 als Tier.

5. Entscheidungstabelle: Reicht das Free-Tier?

Alle Zahlen sind gelistet – die Kernfrage: Überschreitet Ihr Projekt die Limits?

Nach Projekttyp

Projekttyp	Anfragen/Monat	Traffic/Monat	Speicher	Free-Fazit
Persönlicher Blog (statisch)	< 10K	< 1 GB	< 1 GB	✓ Vollständig ausreichend
Tech-Blog (SSR)	< 100K	< 10 GB	< 1 GB	△ Workers evtl. knapp
Kleine API	< 3M	—	< 5 GB	✗ Workers Paid nötig
Bild-Hosting (klein)	—	< 20 GB	< 10 GB	△ R2 evtl. knapp
Bild-Hosting (mittel)	—	> 50 GB	> 10 GB	✗ R2 Paid nötig
Content-Site (500+ Artikel)	—	< 20 GB	—	△ Pages-Dateien knapp
Team-Projekt	Mehrere Entwickler	—	—	✗ Pages parallele Builds Paid

Nach Traffic

Besucher/Tag	Workers-Risiko	Pages-Risiko	CDN-Risiko
< 100	Keins	Keins	Keins
100–500	Keins	Keins	Keins
500–1.000	Niedrig (~15K/Monat)	Keins	Keins
1.000–5.000	Mittel (~150K/Monat)	Niedrig	Keins
5.000–10.000	Hoch	Mittel	Keins
> 10.000	Limit überschritten	Hoch	Keins (außer Video)

Schnell-Checkliste

1. Besucher/Tag?

   • < 100 → alles OK
   • 100–1.000 → Workers beachten

   • 1.000 → Workers-Risiko

2. Dateien/Artikel?

   • < 100 → Pages OK
   • 100–500 → Wachstum beobachten

   • 500 → nahe Pages-Limit

3. Teamgröße?

   • 1 Person → 1 Build OK
   • 2–3 → Blocking möglich

   • 3 → Paid empfohlen

4. User-Dateien?

   • < 5 GB → R2 OK
   • 5–10 GB → fast voll

   • 10 GB → R2 Paid

5. Builds/Tag?

   • < 10/Woche → OK
   • 10–30/Woche → knapp

   • 30/Woche → Überschreitung möglich

Wann upgraden?

Pro-Plan ($20/Monat) bei:

• Workers nahe 80K/Tag
• Pages >400 Builds/Monat
• R2 >8 GB
• Build-Warteschlangen im Team
• Schnell wachsendem Traffic

Pro unlockt:

• Workers: unbegrenzt (Pay-as-you-go, $0,02/Mio.)
• Pages: 100.000 Dateien
• Pages: 5 parallele Builds
• R2: Pay-as-you-go, null Egress
• WAF: volles Managed Ruleset

Bei Skalierung kann $20/Monat günstiger sein als AWS/Vercel Pay-as-you-go – Workers und CDN bleiben kalkulierbar.

Fazit

Die Kernlimits des Free-Tiers: Workers (100.000/Tag), Pages (500 Builds/Monat), R2 (10 GB). CDN und DNS sind „unbegrenzt” – solange kein Video- und Großdatei-Hosting.

Liegt Ihr Projekt im Free-Rahmen, lohnt Cloudflare jetzt: globales CDN, DDoS, SSL – anderswo oft kostenpflichtig.

Nahe den Limits kann Pro ($20/Monat) günstiger sein als überraschende AWS/Vercel-Rechnungen – feste monatliche Kosten statt Billing-Schock.

Monitoring im Voraus: täglich Dashboard, wöchentlich Quota-Nutzung. Nicht erst bei 403 merken, dass das Limit erreicht ist.