Ist EmDash ein echter WordPress-Ersatz?

EmDash kann WordPress schon heute ersetzen, wenn es um inhaltsorientierte Websites mit überschaubarem Plugin-Bedarf geht und das Team sicher mit Astro arbeitet. Für Websites, die auf PHP-Themes, bestimmte WordPress-Plugins oder kostenpflichtige Erweiterungen angewiesen sind, ist es jedoch noch kein Drop-in-Ersatz.

Jeder Kunde, dessen WordPress-Website schon einmal über ein Plugin kompromittiert wurde, hat gefragt, ob es eine sicherere Alternative gibt. Als EmDash mit dem Slogan „spiritual successor to WordPress“ die Version 1.0 erreichte, stellten sich viele Agenturen diese Frage erneut.

Dieser Artikel vergleicht EmDash und WordPress in vier Punkten: Sicherheitsmodell für Plugins, Hosting-Anforderungen, Migration und das, worauf Sie verzichten müssen.

Was ist das EmDash CMS?

EmDash ist ein Open-Source-CMS in TypeScript auf Basis von Astro. Es steht unter der MIT-Lizenz und läuft auf Cloudflare oder auf einem Node.js-Server. In der Ankündigung von EmDash 1.0 durch Cloudflare wird es als stabiles, kostenloses Open-Source-CMS beschrieben, das „bereit ist, eine produktive Website zu betreiben“.

Jede Rolle hat ihren eigenen Zugang. Entwickler erstellen die Website in Astro. Redakteure arbeiten im EmDash-Adminbereich. KI-Agenten können Inhalte über die API, die CLI oder den integrierten Model Context Protocol (MCP)-Server lesen und ändern. Eine neue Website legen Sie so an:

npm create emdash@latest

Laut Cloudflare wurde der eigene Unternehmensblog bereits im August, also vor dem Release von 1.0, auf EmDash umgestellt.

Wie unterscheidet sich das Plugin-Modell von EmDash von dem von WordPress?

Das Plugin-Modell ist der größte Unterschied zwischen beiden Systemen. In WordPress läuft jedes Plugin im selben PHP-Prozess wie die Website und kann auf Datenbank, Dateisystem und Netzwerk zugreifen. Ein sandboxed EmDash-Plugin startet dagegen isoliert und muss jede benötigte Berechtigung einzeln anfordern.

Laut dem Beitrag von Cloudflare zu EmDash 1.0 erhält ein sandboxed Plugin seinen eigenen privaten Speicher und sonst nichts. Inhalte, Medien, Benutzer, Secrets, Umgebungsvariablen, Dateisystem und Netzwerk der Website sind standardmäßig gesperrt. Alles darüber hinaus erhält ein Plugin erst, nachdem es den Bedarf deklariert und der Website-Administrator ihn genehmigt hat – ähnlich wie bei Berechtigungen in einer mobilen App. Cloudflare nennt als Beispiel einen Bildoptimierer: Er fordert Lese- und Verwaltungsrechte für Medien an, kann aber keine Benutzerinhalte lesen.

Die EmDash-Plugin-Registry ist dezentral organisiert. Sie basiert auf dem AT Protocol, und Publisher signieren und speichern ihre eigenen Paket- und Release-Datensätze in ihrem eigenen Atmosphere-Konto. Blendet der EmDash-Katalog einen Eintrag im Rahmen der Moderation aus, bleibt der Publisher dennoch Eigentümer des Plugins und seiner Release-Historie.

Es gibt eine Ausnahme von der Sandbox. Laut der Konfigurationsreferenz ist das Array plugins für Plugins vorgesehen, die sich den Prozess der Astro-Website teilen – dort werden native Plugins eingetragen. Diese Plugins laufen ohne Isolation. Plugins, die aus der Registry installiert werden, durchlaufen dagegen immer die Sandbox.

Sollten Sie EmDash auf Cloudflare oder unter Node.js hosten?

Sie können EmDash auf Cloudflare oder unter Node.js hosten, allerdings funktioniert die Sandbox jeweils unterschiedlich. Cloudflare kostet Geld, setzt aber mehr Limits durch. Der Node.js-Runner verursacht keine Zusatzkosten, setzt jedoch weniger Limits durch.

Diese Voraussetzungen sind in der Dokumentation zur Plugin-Sandbox beschrieben. Ohne Runner überspringt EmDash alle Plugins, die unter sandboxed: [] aufgeführt sind. Eine selbst konfigurierte Registry können Sie weiterhin durchsuchen, doch die Installation oder Aktualisierung eines sandboxed Plugins bricht mit dem Fehler SANDBOX_NOT_AVAILABLE ab. Der Rest der Website funktioniert weiterhin.

Unter Node.js installieren Sie den Node-Adapter und den Sandbox-Runner und verweisen dann in der Konfiguration auf den Runner:

npm install @astrojs/node @emdash-cms/sandbox-workerd workerd

// astro.config.mjs
import { defineConfig } from "astro/config";
import node from "@astrojs/node";
import emdash from "emdash/astro";
import { sqlite } from "emdash/db";

export default defineConfig({
  output: "server",
  adapter: node({ mode: "standalone" }),
  integrations: [
    emdash({
      database: sqlite({ url: "file:./data/emdash.db" }),
      sandboxRunner: "@emdash-cms/sandbox-workerd/sandbox",
    }),
  ],
});

Die Dokumentation zu Capabilities bestätigt, dass der Node.js-Runner nur das Wall-Time-Limit von 30 Sekunden durchsetzt. Legt eine Website Limits für CPU, Arbeitsspeicher oder Subrequests fest, protokolliert der Runner eine Warnung, da ein eigenständiges workerd diese nicht anwenden kann. Unter Node.js wird ein Plugin mit übermäßigem CPU-Verbrauch also erst abgebrochen, wenn es das Wall-Time-Limit erreicht.

Wie migrieren Sie von WordPress zu EmDash?

EmDash migriert Inhalte, keinen Code. Die Dokumentation zum Content-Import nennt zwei Wege für den Import: eine WordPress-eXtended-RSS-Datei (WXR) oder eine Verbindung zu einer Website, auf der das Plugin EmDash Exporter läuft. Für WordPress.com gibt es keine eigene Importquelle, daher nutzen auch diese Websites einen WXR-Export oder den EmDash Exporter.

Der Leitfaden zur Migration von WordPress warnt, dass ein Exporter vor Version 1.2.0 Kommentare, Menüs, Logo und Favicon stillschweigend verwirft. Der Import wird trotzdem abgeschlossen und meldet nichts als fehlend. Prüfen Sie daher vor dem Start die Version des Exporters. Für Themes und Plugins verweist das EmDash-README auf Agent Skills, die bei der Portierung helfen. Rechnen Sie aber auch mit dieser Unterstützung mit einer Neuentwicklung.

Wo hat WordPress weiterhin die Nase vorn?

WordPress behält vier praktische Vorteile: Es verfügt über ein weitaus größeres Ökosystem an Themes und Plugins, nahezu jeder Hoster unterstützt es, Redakteure kennen es bereits, und es gibt einen ausgereiften Markt für kostenpflichtige Plugins. Zum Launch von 1.0 erklärte Cloudflare, dass die EmDash-Registry ausschließlich kostenlose Plugins unterstützt; kostenpflichtige Plugins sind für später geplant.

Das Hosting ist die zweite Lücke. WordPress läuft auf nahezu jedem PHP-Hoster. Die vollständige Plugin-Sandbox von EmDash erfordert entweder einen kostenpflichtigen Cloudflare-Plan oder einen selbst betriebenen Node.js-Server.

Die dritte Hürde betrifft die Redakteure. Der EmDash-Adminbereich ist für sie neu, die Umstellung eines Kunden bedeutet also nicht nur den Umzug von Inhalten, sondern auch die Schulung des Personals. Wenn Sie mehrere WordPress-Alternativen abwägen, zeigt der Vergleich von 11ty und WordPress, wie sich diese Abwägungen bei einer Static-first-Lösung auswirken.

Wer EmDash jetzt ausprobieren und wer noch warten sollte

Probieren Sie es jetzt aus, wenn:

• Sie Content-Websites wie Blogs, Dokumentationen oder Marketingseiten erstellen und Ihr Team bereits mit Astro arbeitet.
• das Supply-Chain-Risiko durch Plugins für Sie oder Ihre Kunden ein reales Thema ist.
• Agents über die API, die CLI oder den MCP-Server mit Inhalten arbeiten sollen.

Warten Sie noch, wenn:

• die Website von einem bestimmten WordPress-Plugin, einem kommerziellen Theme oder Funktionen à la WooCommerce abhängt.
• Sie kostenpflichtige Plugins aus der Registry benötigen.
• Ihr Hosting günstiges Shared PHP Hosting sein muss.

Wenn Sie auf Cloudflare deployen, lohnt sich ein Blick auf cf, die neue Cloudflare-CLI, die am 28. September 2026 in die offene Beta gestartet ist. Sie verwaltet die Workers-Konfiguration und Bindings über eine Datei cloudflare.config.ts, während Wrangler weiterhin Projekte verwaltet, die mit wrangler.jsonc konfiguriert sind.

EmDash ist ein echter WordPress-Ersatz für eine bestimmte Art von Website: inhaltsgetrieben, mit wenigen Plugins und umgesetzt von einem Astro-erfahrenen Team, dem sandboxed Plugins wichtiger sind als die Größe des Ökosystems. Für alle anderen Fälle lohnt sich ein Pilotprojekt, ein Umstieg ist aber noch nicht ratsam. Ein guter nächster Schritt: Führen Sie den WXR-Export einer echten Kunden-Website durch den Importer und dokumentieren Sie, was fehlt.

FAQs

Kann EmDash eine WordPress-Website allein anhand ihrer URL importieren?

Nein. Ohne das Plugin EmDash Exporter kann EmDash über eine Website-URL lediglich die öffentliche WordPress REST API abfragen. Diese Prüfung kann bestätigen, dass die Website mit WordPress läuft, und die öffentlichen Beiträge, Seiten und Medien zählen, aber nichts importieren. Für den Import laden Sie eine WXR-Exportdatei hoch oder installieren den EmDash Exporter auf der WordPress-Website und verbinden sich mit einem WordPress-Anwendungspasswort. Damit erreichen Sie auch Inhalte, die die öffentliche REST API nicht bereitstellt.

Was passiert beim Import in EmDash mit Gutenberg-Blöcken und Plugin-Blöcken?

EmDash wandelt Gutenberg-Markup in Portable Text um und verarbeitet HTML aus dem klassischen Editor mit demselben Konverter. Blöcke, die WordPress serverseitig rendert, etwa Neueste Beiträge oder viele Plugin-Blöcke, speichern kein Markup im Beitrag. Der Importer übernimmt jeden dieser Blöcke als HTML-Block, der nur den ursprünglichen Block-Kommentar enthält und auf der Website nichts anzeigt. Sie müssen diese Blöcke daher neu erstellen oder löschen. Wiederverwendbare Blöcke werden zu EmDash-Sections.

Behalten Entwürfe, geplante und private Beiträge aus WordPress ihren Status in EmDash?

Nur veröffentlichte Beiträge bleiben veröffentlicht. Der EmDash-Importer bildet den WordPress-Status publish auf published ab, während die Status draft, pending, private, future, trash sowie unbekannte Status allesamt zu Entwürfen werden. Geplante und private Beiträge müssen nach dem Import daher manuell geprüft werden. Der EmDash-Migrationsleitfaden empfiehlt außerdem, die Einträge nach Status zu zählen und zu prüfen, ob Entwürfe für nicht angemeldete Besucher verborgen bleiben, bevor Sie das DNS umstellen oder die WordPress-Website abschalten.

Welche Datenbanken und Storage-Backends unterstützt EmDash?

EmDash nutzt Kysely für SQL und die S3-API für Storage. Für Daten funktioniert es daher mit SQLite, Cloudflare D1, Turso bzw. libSQL und PostgreSQL, für Medien mit Cloudflare R2, AWS S3, jedem S3-kompatiblen Dienst oder dem lokalen Dateisystem. Auf Cloudflare lesen und schreiben sandboxed Plugins dennoch über ein D1-Binding namens DB – unabhängig davon, welchen Datenbankadapter die Website selbst verwendet.