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.
Kurzfassung: Die architektonischen Entscheidungen sind richtig. 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 einige 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 gekennzeichnet und ich stimme zu. Die Wahl von TinyMCE statt eines blockbasierten Editors wie Gutenberg oder Sanitys Portable Text wirkt wie ein Rückschritt. Block-basierte Bearbeitung ist wirklich besser für strukturierte Content-Workflows, Multi-Channel-Publishing und KI-gestützte Inhalte. Das Argument für TinyMCE — „Nutzer sind damit vertraut" — ist dasselbe Argument, das WordPress 5 Jahre lang dazu gebracht hat, Gutenberg zu verzögern, und dann schlecht ausgeliefert. emdash hatte die Chance, mit einem blockbasierten Editor zu starten; die Wahl von TinyMCE gibt Early Adopters weniger als das, was Sanity, Storyblok und sogar modernes WordPress auf der redaktionellen Seite bieten 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 Long-Tail von Etsy-Shop-Blog-Machern zu sein. Es versucht, das richtige architektonische Fundament für ernsthafte Content-Led-Teams zu sein, die WordPress überwachsen haben und einen modernen Stack wollen. Aber die Marketing-Positionierung muss passen: emdash ist die richtige Antwort für einige 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 Production-Sites, die bis mindestens v1.0 Stabilität brauchen. Marketing-Team-geführte Projekte, bei denen Editor-Erlebnis der entscheidende Faktor ist (Sanity, Storyblok, Contentful gewinnen da alle). WordPress-Migrationen, bei denen das Plugin-Ökosystem echte Arbeit für dich leistet. Kostenempfindliche Long-Tail-Blogs, bei denen Shared-PHP-Hosting für $4/Monat die richtige Antwort ist. Teams, die Developer aus einem großen Pool einstellen müssen — der emdash-Hiring-Pool ist klein.
Meine Empfehlung für 2026
Nutze emdash zuerst bei einem Sideprojekt. Baue etwas Echtes damit — dein persönliches Blog, ein internes Tool, eine Dokumentations-Website. Lerne das Plugin-Modell kennen, 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 Production auch richtig anfühlen. Falls ja, wird emdash eine ernsthafte Option für Greenfield-Projekte 2027. Falls der Editor-Aufwand oder die Ökosystem-Lücke der Dealbreaker sind, sagt dir die Erfahrung 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 ursprüngliche ehrliche Bewertung willst, ist Maciek Palmowskis Text auf maciekpalmowski.dev die kanonische Referenz. Das emdash-Projekt lebt auf emdashcms.dev mit dem Source auf GitHub. Wenn du einen CMS-Choice für dein spezifisches Projekt durchsprechen willst — emdash, Sanity, Storyblok, Payload, Decap, Tina, Hygraph, headless WordPress oder etwas anderes — ist das 30-Min-Call der richtige Anfang. Die /developers/emdash/-Seite auf dieser Website zeigt, wie ein emdash-Development-Engagement in der Praxis aussieht.