
Cloudflares Real Play – Warum EmDash kein CMS ist, sondern ein Infrastruktur-Trojanisches-Pferd
TL;DR: „EmDash ist nicht das Produkt. D1 + R2 + Workers ist das Produkt. Cloudflare will das Default-Backend für AI-generierte Software werden – und WordPress-Traffic ist nur der Einstieg."
— Till FreitagDie offensichtliche Story
Cloudflare hat ein Open-Source-CMS namens EmDash veröffentlicht. Full-Stack TypeScript, gebaut auf Astro, läuft auf D1, R2 und Workers. Die technische Analyse findest du hier.
Die Presse schreibt: „Cloudflare greift WordPress an."
Das ist die offensichtliche Story. Und sie ist falsch.
Die eigentliche Story
Cloudflare sitzt auf einem der größten Echtzeit-Datensätze über das Internet. Sie betreiben DNS für Millionen von Domains. Sie sehen Traffic-Patterns, Technologie-Stacks, Bot-Aktivität und Performance-Metriken – in Echtzeit, weltweit.
Cloudflare sieht den WordPress-Decline, bevor er in den Gartner-Reports auftaucht.
Sie sehen:
- Welche Domains von WordPress zu Jamstack migrieren
- Wie viel Traffic AI-generierte Seiten bereits erzeugen
- Welche Frameworks wachsen (Astro, Next.js, Remix)
- Wie sich die Ratio von menschlichen vs. Bot-Requests verschiebt
Und aus diesen Daten leiten sie eine strategische These ab:
Die nächste Generation von Websites wird nicht von Menschen gebaut. Sie wird von AI generiert. Und diese AI braucht ein Backend.
Das Trojanische Pferd
EmDash ist nicht das Produkt. EmDash ist der Proof of Concept.
Es zeigt: „Schau, ein komplettes CMS mit Auth, Storage, Datenbank, Plugins und Agent-Integration – alles auf unserem Stack. Kein AWS. Kein Vercel. Kein externer Dienst."
Jedes EmDash-Projekt, das live geht, bedeutet:
| Ressource | Cloudflare-Produkt | Revenue-Stream |
|---|---|---|
| Datenbank | D1 (SQLite at Edge) | Pay-per-query |
| Datei-Storage | R2 (S3-kompatibel) | Pay-per-GB |
| Compute | Workers | Pay-per-request |
| DNS/CDN | Cloudflare Network | Bestehende Infrastruktur |
Ein einzelnes CMS? Irrelevant für die Bilanz. Tausende von AI-generierten Apps, die alle auf D1 + R2 + Workers laufen? Das ist eine Infrastruktur-Strategie.
Der AI-Builder-Markt
Hier wird es interessant. Schau dir an, was gerade passiert:
Lovable generiert Full-Stack-React-Apps per Chat. Bolt baut Prototypen in Sekunden. v0 von Vercel rendert UI-Komponenten aus Prompts. Cursor und Windsurf beschleunigen professionelle Entwicklung um den Faktor 10.
All diese Tools haben ein gemeinsames Problem: Sie generieren Frontends brillant – aber wohin mit dem Backend?
- Lovable nutzt Supabase (PostgreSQL + Auth + Storage)
- Bolt deployed auf Netlify
- v0 pushed natürlich zu Vercel
Cloudflare sieht die Opportunity: Wenn sie das natürlichste, einfachste Backend für AI-generierte Apps werden, fangen sie den gesamten AI-Builder-Markt ab – unabhängig davon, welches Frontend-Tool gewinnt.
EmDash beweist, dass der Stack funktioniert. Der nächste logische Schritt: Ein npx create-cloudflare-app für Lovable, Bolt und Co., das D1 + R2 + Workers als One-Click-Backend bereitstellt.
Die Vercel-Flanke
Das ist gleichzeitig ein direkter Angriff auf Vercel.
Vercels Geschäftsmodell basiert darauf, dass Next.js-Apps auf ihrer Infrastruktur deployed werden. Vercel hat v0 gebaut, um noch mehr Apps auf ihre Plattform zu ziehen. Das Playbook: AI generiert das Frontend → Vercel hostet es → Lock-in über Serverless Functions und Edge Runtime.
Cloudflare kontert mit einem vollständigen Gegenentwurf:
| Vercel | Cloudflare |
|---|---|
| Serverless Functions | Workers |
| Edge Config | KV |
| Blob Storage | R2 |
| Postgres (Neon) | D1 |
| v0 (eigener AI Builder) | EmDash (Open Source + Partner-Ökosystem) |
Der entscheidende Unterschied: Vercel baut einen geschlossenen Flywheel (v0 → Vercel Hosting → Lock-in). Cloudflare baut ein offenes Flywheel (EmDash/jeder AI Builder → Cloudflare Infrastruktur → kein Lock-in, aber Convenience).
Open-Source-Infrastruktur mit niedrigen Switching-Costs gewinnt langfristig gegen proprietäre Plattformen. AWS hat das bewiesen.
Die WordPress-Migration als Turbo
WordPress hat über 40% Marktanteil. Das sind Hunderte Millionen von Websites. Selbst wenn nur 5% in den nächsten 5 Jahren migrieren, sind das Millionen von Projekten, die ein neues Backend brauchen.
EmDash hat einen eingebauten WordPress-Import-Wizard. Das ist kein Feature. Das ist Customer Acquisition.
Jede WordPress-Seite, die zu EmDash migriert, wird automatisch ein Cloudflare-Infrastruktur-Kunde. D1 für die Datenbank. R2 für die Media Library. Workers für die Logik. Und sobald sie auf dem Stack sind, ist die Wahrscheinlichkeit hoch, dass sie dort bleiben.
Was das für Unternehmen bedeutet
Wenn du heute über deine CMS- oder Web-Infrastruktur-Strategie nachdenkst, sind das die relevanten Fragen:
1. Wo liegt dein Backend in 3 Jahren?
Die Ära von „ich hoste alles auf einem VPS" geht zu Ende. Die Frage ist nicht ob Serverless, sondern welches Serverless. Cloudflare, AWS oder Vercel?
2. Wie AI-ready ist deine Infrastruktur?
Wenn dein nächstes Projekt von einer AI generiert wird – welches Backend bietet sich natürlich an? Je einfacher die Integration, desto wahrscheinlicher wirst du dort landen.
3. Willst du Lock-in oder Portabilität?
Cloudflares D1 ist SQLite-kompatibel. R2 ist S3-kompatibel. Workers nutzen Standard Web APIs. Das ist bewusst so gewählt: niedrige Switching-Costs als strategischer Vorteil.
Fazit: Nicht das CMS beobachten – den Stack
EmDash wird wahrscheinlich nie WordPress in Marktanteilen schlagen. Das muss es auch nicht.
Wenn Cloudflare es schafft, D1 + R2 + Workers als das natürliche Backend für die nächste Generation von AI-generierten Websites und Apps zu positionieren, ist EmDash der erfolgreichste Marketing-Move der Firmengeschichte.
Die Wette ist nicht EmDash vs. WordPress.
Die Wette ist Cloudflare-Infrastruktur vs. AWS/Vercel als Default-Backend für AI-generierte Software.
Und wenn du dir anschaust, wie aggressiv Cloudflare Preise senkt, Developer Experience verbessert und Open-Source-Tools baut – dann ist das eine Wette, die sie gewinnen könnten.








