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.Astro-first, capability-bounded plugins, per-post-type database tables, AI agents as first-class builders via MCP. Maciek Palmowski wrote a sharp early review at maciekpalmowski.dev that captured the architectural promise alongside the editor-experience compromise. This is my honest take after digging into the codebase, the docs, and what the project is actually trying to be.
Kurzversion: die Architektur-Entscheidungen sind richtig. Die Editor-Wahl ist fragwürdig. Die Preisgestaltung ist unschlagbar (kostenlos, MIT). Das Publikum ist enger als das Marketing suggeriert, und das ist okay -- die richtige WordPress-Alternative für manche Teams ist nicht die richtige WordPress-Alternative für alle Teams. Hier ist die längere Version.WordPress alternative for some teams is not the right WordPress alternative for all teams. Here is the longer 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 Review hat das gekennzeichnet und ich stimme zu. Die Wahl von TinyMCE statt eines Block-basierten Editors wie Gutenberg oder Sanitys Portable Text wirkt wie ein Schritt zurück. Block-basierte Bearbeitung ist wirklich besser für strukturierte Content-Workflows, Multi-Channel-Publishing und AI-gestützte Inhalte. Das Argument für TinyMCE -- "Nutzer kennen das bereits" -- ist dasselbe Argument, das WordPress nutzten, um Gutenberg um fünf Jahre zu verschieben und es dann schlecht auszurollen. emdash hatte die Chance, mit einem Block-basierten Editor zu starten; die Wahl von TinyMCE gibt Early Adoptern weniger, als Sanity, Storyblok und selbst modernes WordPress auf der Editorial-Seite anbieten können.Sanity's Portable Text feels like a step backward. Block-based editing is genuinely better for structured content workflows, multi-channel publishing, and AI-assisted content. The argument for TinyMCE, "users are familiar with it", is the same argument WordPress used to delay Gutenberg by five years and then ship it badly. emdash had the chance to start with a block-based editor; choosing TinyMCE gives early adopters less than what Sanity, Storyblok, and even modern WordPress can offer on the editorial side.
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 okay -- emdash versucht nicht, WordPress für die Long-Tail von Etsy-Shop-Blog-Machern zu sein. Es versucht, die richtige Architektur-Grundlage für ernsthafte, inhaltsgetriebene Teams zu sein, die WordPress outgrown haben und einen modernen Stack wollen. Aber die Marketing-Positionierung muss dazu passen: 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
Produktionskritische Sites, die Stabilität bis mindestens v1.0 brauchen. Marketing-Team-geführte Projekte, wo Editor-Erlebnis der entscheidende Faktor ist (Sanity, Storyblok, Contentful gewinnen alle dort). WordPress-Migrationen, wo das Plugin-Ökosystem echte Arbeit für dich leistet. Kostenempfindliche Long-Tail-Blogs, wo gemeinsames PHP-Hosting bei $4/Monat die richtige Antwort ist. Teams, die Entwickler aus einem breiten Pool einstellen müssen -- der emdash-Talent-Pool ist klein.
Meine Empfehlung für 2026
Benutze emdash zuerst bei einem Seitenprojekt. Baue etwas Echtes damit -- dein persönlicher Blog, ein internes Tool, eine Dokumentations-Site. Bekommen ein Gefühl für das Plugin-Modell, das Editor-Erlebnis, die Deployment-Story. Nach 6-12 Wochen weißt du, ob die Architektur-Entscheidungen, die auf dem Papier richtig aussehen, sich in der Produktion auch richtig anfühlen. Wenn ja, wird emdash eine ernsthafte Option für Greenfield-Projekte 2027. Wenn die Editor-Schmerzen oder die Ökosystem-Lücke der Dealbreaker ist, 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, Maciek Palmowskis Artikel auf maciekpalmowski.dev ist die kanonische Referenz. Das emdash-Projekt lebt auf emdashcms.dev mit dem Source auf GitHub. Wenn du eine CMS-Wahl für dein spezifisches Projekt durchsprechen willst -- emdash, Sanity, Storyblok, Payload, Decap, Tina, Hygraph, headless WordPress oder etwas anderes -- ist das 30-Minuten-Gespräch der richtige Startpunkt. Die /developers/emdash/-Seite auf dieser Site zeigt auf, 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.