Cloudflare hat emdash CMS Anfang April 2026 als v0.1.0 Preview veröffentlicht. Das Versprechen: Open-Source, MIT-lizenziert, Astro-first, Capability-bounded Plugins, dedizierte Datenbanktabellen pro Post-Typ, AI-Agenten als First-Class Builder via MCP. Maciek Palmowski hat eine scharfsinnige frühe Bewertung auf maciekpalmowski.dev geschrieben, die das architektonische Potenzial neben dem Editor-Experience-Kompromiss eingefangen hat. Das ist meine ehrliche Einschätzung nach dem Durcharbeiten der Codebase, der Docs und dem, was das Projekt eigentlich sein soll.
Kurzversion: Die Architektur-Entscheidungen sind korrekt. Die Editor-Wahl ist fragwürdig. Die Preisgestaltung ist unschlagbar (kostenlos, MIT). Die Zielgruppe ist enger als das Marketing suggeriert, und das ist in Ordnung – die richtige WordPress-Alternative für manche Teams ist nicht die richtige WordPress-Alternative für alle Teams. Hier ist die längere Version.
Was emdash eigentlich ist, in einem Absatz
emdash ist ein Content-Management-System, geschrieben in TypeScript, gebaut auf Astro, standardmäßig deployed auf Cloudflare Workers (mit Node.js Fallback). Es positioniert sich als Nachfolger von WordPress mit drei architektonischen Unterschieden: (1) Plugin-Berechtigungen sind explizit und Capability-bounded statt implizit und mit vollständigem Zugriff, (2) jeder Post-Typ lebt in seiner eigenen dedizierten Datenbanktabelle, statt in das WordPress wp_posts/wp_postmeta Muster gezwängt zu werden, (3) AI-Integration ist first-class via einen eingebauten MCP Server und eine JSON CLI, die es Agenten ermöglicht, sauber Content zu lesen und zu schreiben. Open-Source, MIT-lizenziert, aktuell v0.1.0 Preview seit April 2026.
Was an emdash richtig ist
Das Sicherheitsmodell von Plugins ist eine echte architektonische Verbesserung
WordPress-Plugin-Sicherheit ist im bestehenden Modell unlösbar. Plugins laufen im selben Prozess wie der Kern, mit demselben Datenbankzugriff, demselben Dateisystem-Zugriff und der gleichen Möglichkeit, überall in den Request-Lebenszyklus einzugreifen. Ein kompromittiertes Plugin kompromittiert die gesamte Website. emdash dreht das um: Plugins deklarieren die benötigten Berechtigungen im Voraus (read-content, write-content, send-email usw.) und laufen innerhalb expliziter Capability-Grenzen. Ein Plugin, das „send-email" anfordert, kann nicht plötzlich anfangen, in die Datenbank zu schreiben. Ein Plugin, das „read-content" anfordert, kann keine Benutzerpasswörter abzapfen.
Das ist die gleiche Idee wie iOS-App-Berechtigungen, Browser-Erweiterungs-Berechtigungen und Capability-Based Security im Allgemeinen. Es ist seit 50 Jahren die richtige Antwort und WordPress hat sich aus Gründen der Abwärtskompatibilität 22 Jahre lang dagegen gewehrt. emdash von dieser Position aus zu starten ist der architektonische Reset, auf den die WordPress-Welt gewartet hat.
Dedizierte Tabellen pro Post-Typ
WordPress quetscht alle Posts, Seiten, Custom Post Types und Revisionen in eine einzelne wp_posts-Tabelle mit Type-Diskriminator. Custom Fields gehen als Schlüssel-Wert-Zeilen an wp_postmeta. Das Ergebnis: Das Abfragen eines Custom Post Types mit drei Taxonomien und 12 ACF-Feldern trifft 4–5 Tabellen mit mehreren JOINs und ist die Hauptquelle für langsame WordPress-Page-Builds. emdash gibt jedem Post-Typ eine eigene Tabelle mit richtig ausgestatteten Spalten. Das Abfragemuster ist natürlicherweise schneller, die Index-Strategie ist natürlicherweise sauberer, und 50.000er-Sites brauchen nicht die 17 Caching-Plugins, die WordPress-Sites zur Kompensation der Schema-Entscheidung nutzen.
KI-orientierte Integration über MCP
Die meisten CMS, die 2026 „KI unterstützen", bedeuten, dass sie einen OpenAI-API-Aufruf an einen WYSIWYG geklickt haben. emdash liefert direkt einen MCP-Server (Model Context Protocol) plus eine JSON-CLI aus. Agents können Inhalte durch einen strukturierten Vertrag lesen und schreiben, statt HTML zu scrapen oder Browser-Sitzungen zu simulieren. Das ist die richtige Abstraktion für die KI-gesteuerten Content-Workflows, die 2026 entstehen; Agents als erstklassige Builder zu behandeln statt sie nachträglich zu integrieren ist ein echter Differenzierer.
TypeScript end-to-end + Astro
Moderner Stack, modernes Tooling, kein PHP. Typsicherheit von der Schema-Definition über die API bis zum Frontend. Astro für die Rendering-Schicht bringt das schnell-standardmäßig static-with-islands-Muster. Für entwicklergeführte Teams 2026 ist das der richtige Stack, um zu starten. WordPress hat jahrelang keine sinnvolle Editor-Experience-Verbesserung gehabt; emdash kommt dort hin, indem man von vorne anfängt.
Was ist falsch (oder zumindest fragwürdig)
TinyMCE 2026 ist nicht die richtige Editor-Wahl
Macieks Bewertung hat das angesprochen und ich stimme zu. Die Wahl von TinyMCE statt eines Block-basierten Editors wie Gutenberg oder Sanitys Portable Text fühlt sich wie ein Rückschritt an. Block-basiertes Editing ist genuinely besser für strukturierte Content-Workflows, Multi-Channel-Publishing und AI-unterstützte Inhalte. Das Argument für TinyMCE – „Nutzer sind damit vertraut" – ist dasselbe Argument, das WordPress nutzte, um Gutenberg um fünf Jahre zu verzögern und es dann schlecht auszuliefern. emdash hatte die Chance, mit einem Block-basierten Editor zu starten; die Wahl von TinyMCE gibt frühen Nutzern weniger als das, was Sanity, Storyblok und sogar modernes WordPress auf der redaktionellen Seite anbieten können.
Es löst nicht die tatsächlichen Schmerzenspunkte von WordPress-Nutzern
WordPress-Nutzer bleiben bei WordPress nicht wegen Plugin-Berechtigungen. Sie bleiben, weil (a) Hosting billig und reichlich vorhanden ist, (b) das Plugin-Ökosystem häufige Probleme direkt löst, (c) WordPress-Entwickler zu finden einfach ist. emdash macht Hosting noch nicht billiger (Cloudflare Workers ist okay, aber nicht kostenlos in großem Maßstab, und selbst gehostetes Node.js ist mehr operative Arbeit als ein 4 Dollar/Monat WordPress-Host). Das Plugin-Ökosystem ist leer bei v0.1.0. WordPress-Entwickler gibt es in Millionen; emdash-Entwickler gibt es in Dutzenden. Keine dieser Dinge wird sich schnell verbessern.
Das ist in Ordnung, emdash versucht nicht, WordPress für die lange Tail von Etsy-Shop-Blog-Machern zu sein. Es versucht, die richtige architektonische Grundlage für ernsthafte, Content-geführte Teams zu sein, die WordPress outgrown haben und einen modernen Stack wollen. Aber die Marketing-Positionierung muss stimmen: emdash ist die richtige Antwort für manche Teams, nicht für die WordPress-Mehrheit.
Plugin-Ökosystem ist leer (und wird es 12–24 Monate lang sein)
Greenfield-CMSs sehen sich immer dem Bootstrap-Problem gegenüber: der Wert der Plattform skaliert mit Plugin-Verfügbarkeit, und Plugins werden erst gebaut, wenn die Plattform Nutzer hat, und Nutzer adoptieren erst, wenn die Plugins existieren. emdash wird das langsam lösen. In den nächsten 12–24 Monaten werden Projekte auf emdash bedeuten, das SEO-Plugin, das Sitemap-Plugin, das Multi-Language-Plugin, den Form-Handler und die Email-Newsletter-Integration als First-Party-Arbeit zu schreiben. Planen Sie dafür.
Cloudflare Workers Vendor Lock-in als Standard
Cloudflare Workers ist das primäre Deployment-Ziel. Node.js wird unterstützt, aber die Docs bevorzugen Workers-zuerst. Für Teams, die bereits auf Cloudflare sind, ist das ein Feature. Für Teams, die Stack-Unabhängigkeit wollen, liest sich das als architektonische Lock-in von Anfang an. Der Trade-off ist in jedem Fall real; dass emdash Cloudflare-nativ ist, ist konsistent mit seiner Herkunft, bedeutet aber eine Investition in das Cloudflare-Ökosystem statt in eine portable Abstraktion.
Wo emdash passt und wo nicht
Wo es passt
Greenfield-Content-Led-Projekte auf Cloudflare Workers + Astro, die von Tag eins an die richtige Architektur brauchen. Security-sensitive Deployments, die die WordPress-Plugin-Angriffsfläche satt haben. AI-native Content-Workflows, bei denen MCP-Integration wichtig ist. Developer-geführte Teams mit der Bereitschaft, eine v0.x-CMS zu akzeptieren, um an der Spitze dabei zu sein.
Wo es nicht passt
Mission-kritische Produktionsseiten, die bis mindestens v1.0 Stabilität brauchen. Marketing-Team-geführte Projekte, wo Editor-Erlebnis der entscheidende Faktor ist (Sanity, Storyblok, Contentful gewinnen dort alle). WordPress-Migrationen, bei denen das Plugin-Ökosystem echte Arbeit für dich leistet. Cost-sensitive Long-Tail-Blogs, bei denen Shared-PHP-Hosting für 4 $/Monat die richtige Antwort ist. Teams, die Entwickler aus einem tiefen Pool rekrutieren müssen – der emdash-Rekrutierungspool ist klein.
Meine Empfehlung für 2026
Nutze emdash erst bei einem Side-Project. Baue etwas Echtes damit, dein persönliches Blog, ein internes Tool, eine Dokumentationsseite. Spür das Plugin-Modell, das Editor-Erlebnis, die Deployment-Story. Nach 6–12 Wochen wirst du wissen, ob die Architektur-Entscheidungen, die auf dem Papier richtig aussehen, sich in der Produktion tatsächlich richtig anfühlen. Wenn ja, wird emdash 2027 eine ernsthafte Option für Greenfield-Projekte. Wenn der Editor-Schmerz oder die Ökosystem-Lücke der Deal-Breaker ist, sagt dir das Erlebnis schnell Bescheid.
Meine professionelle Voreingenommenheit: Ich arbeite mit Teams, die heute Shipping-Ready-CMS-Lösungen brauchen. Für 2026-Client-Arbeit ist emdash zu früh. Für 2027-Greenfield könnte es das Standard-Setup für die richtige Project-Form werden. Die Architektur ist korrekt; die Reife ist noch nicht da. Diese Lücke schließt sich Quartal für Quartal.
Wo es weitergeht
Wenn du die Original-Bewertung mit ehrlicher Meinung möchtest, ist Maciek Palmowskis Artikel auf maciekpalmowski.dev die kanonische Referenz. Das emdash-Projekt lebt auf emdashcms.dev mit dem Source auf GitHub. Wenn du einen CMS-Wahl für dein spezifisches Projekt durchdenken möchtest – emdash, Sanity, Storyblok, Payload, Decap, Tina, Hygraph, Headless WordPress oder etwas anderes – ist das 30-minütige Gespräch der richtige Startpunkt. Die /developers/emdash/-Seite auf dieser Website skizziert, wie ein emdash-Development-Engagement in der Praxis aussieht.
Häufig gestellte Fragen
Was ist emdash CMS?
emdash ist ein quelloffenes, MIT-lizenziertes CMS, das Cloudflare im April 2026 als v0.1.0-Vorschau veröffentlicht hat. Es ist Astro-first, mit fähigkeitsbegrenzten sandboxierten Plugins, datenbankabellen pro Inhaltstyp und KI-Agenten, die über MCP als First-Class-Builder behandelt werden. Es wird als WordPress-Alternative positioniert.
Ist emdash CMS produktionsreif?
Nicht im Jahr 2026. Es wurde als v0.1.0-Vorschau veröffentlicht und ist daher absichtlich in einem frühen Stadium. Die Architektur ist wirklich interessant und beobachtenswert, aber es fehlen das Ökosystem und die Reife, um die meisten produktiven Seiten heute zu betreiben. Betrachte es als Vorschau, noch nicht als Migrationsziel.
Was ist interessant an der emdash-CMS-Architektur?
Drei Dinge: fähigkeitsbegrenzte sandboxierte Plugins, die einschränken, was Erweiterungen tun können, datenbankabellen pro Inhaltstyp anstelle einer Universaltabelle, und KI-Agenten als First-Class-Builder durch MCP. Es ist ein neuer Ansatz zum CMS-Design und kein WordPress-Klon.
Sollte ich von WordPress zu emdash wechseln?
Noch nicht. WordPress bleibt 2026 für die meisten Teams die richtige Antwort bei Ökosystem, Reife und Editor-Erfahrung. emdash lohnt sich wegen seiner Architektur zu beobachten, aber eine echte Seite auf eine v0.1.0-Vorschau zu migrieren ist verfrüht. Überdenke es, wenn es reift.