Ist EmDash an Cloudflare gekettet? Ein Faktencheck

Geprüft mit EmDash 1.2.0 auf Node.js 24 am 9. Oktober 2026, mit dem Quellcode von EmDash und der offiziellen Doku.

Kurz nach dem Release von EmDash 1.0 hat Roger Montti bei Search Engine Journal einen Artikel mit einem deutlichen Titel veröffentlicht: „EmDash 1.0 Challenges WordPress Freedom With Cloudflare Lock-In“ (Artikel). Seine These: EmDash sei zwar modern und sicherer als WordPress, binde dich aber an die Infrastruktur von Cloudflare. Fast alle Funktionen von 1.0 hingen an Cloudflare, und selbst das dezentrale Plugin-Verzeichnis stehe unter Cloudflares Kontrolle.

Bevor du weiterliest, zwei Dinge, die du wissen solltest. Ich bin Maintainer bei EmDash, und diese Website läuft auf Cloudflare. Ich habe also einen Grund, EmDash gut aussehen zu lassen. Deshalb habe ich mich nicht auf meine Meinung verlassen, sondern jede Behauptung am Quellcode und an der Doku geprüft und EmDash ohne Cloudflare auf einem Node.js-Server laufen lassen, inklusive Plugin aus dem Verzeichnis.

Das Ergebnis: Montti liegt bei einigen Punkten richtig, bei der Kernaussage aber daneben. EmDash ist nicht an Cloudflare gekettet. Auf Cloudflare ist es nur deutlich bequemer.

Was der Artikel behauptet

Montti macht vier Punkte, die sich prüfen lassen:

1. Viele Funktionen hängen an Cloudflare und machen es schwierig, EmDash ohne Cloudflare zu hosten.
2. Alle vier neuen Funktionen von 1.0 binden dich an Cloudflare.
3. Das Plugin-Verzeichnis ist trotz dezentralem Ansatz unter Cloudflares Kontrolle.
4. Alles, was EmDash an KI-Funktionen bietet, geht auch mit WordPress.

Dazu kommen zwei Wertungen: Cloudflare sei kein Open-Source-Unternehmen, und das Vorgehen erinnere an Google. Darauf komme ich am Schluss zurück.

Läuft EmDash ohne Cloudflare?

Ja, und zwar offiziell. Die Doku hat eine eigene Anleitung für Node.js (Doku). Sie verlangt Node.js 22.16 oder neuer und zeigt eine Konfiguration mit SQLite und lokalem Speicher für einen einzelnen Server, dazu ein Dockerfile. Wer mehrere Server betreibt, nimmt PostgreSQL oder libSQL als Datenbank und für Medien einen S3-kompatiblen Speicher wie MinIO. Der Code von EmDash steht unter der MIT-Lizenz (Lizenz).

Das wollte ich nicht nur lesen. Also habe ich mit dem offiziellen Installer eine neue Site für Node.js angelegt:

npm create emdash@latest meine-site -- --template blog --platform node

Das Anlegen samt Installation dauerte 50 Sekunden, der Build 9 Sekunden. Danach lief die Site mit node ./dist/server/entry.mjs auf meinem Mac, mit SQLite als Datei im Projektordner. Die Startseite kam beim ersten Aufruf nach 441 Millisekunden, und EmDash hat die Standardinhalte beim ersten Start selbst angelegt. Kein Cloudflare-Konto, kein Wrangler, keine Bindings.

Ein Punkt ist auf Node.js anders als auf Cloudflare: Geplante Veröffentlichungen, Plugin-Aufgaben und die Wartung laufen nur, solange der Node-Prozess läuft (Doku). Auf einem normalen Server ist das selbstverständlich, bei Hostern, die Prozesse schlafen legen, nicht.

Und die Plugins?

Hier wird es interessant, denn die Sandbox ist das Aushängeschild von EmDash. Auf Cloudflare läuft jedes Plugin als eigener Worker über das Worker Loader Binding, das es nur im bezahlten Workers-Plan gibt. Auf Node.js startet EmDash stattdessen workerd, die quelloffene Laufzeit hinter Cloudflare Workers, als eigenen Prozess und führt die Plugins darin aus (Doku).

Der Installer richtet das auf Node.js allerdings nicht ein. Die Option für Sandbox-Plugins gilt laut Hilfetext nur für Cloudflare, und meine neue Site hatte keine Sandbox, obwohl ich die Option mitgegeben hatte. Nachrüsten war einfach:

npm install @emdash-cms/sandbox-workerd workerd

Dazu eine Zeile in astro.config.mjs:

emdash({
	// ...
	sandboxRunner: "@emdash-cms/sandbox-workerd/sandbox",
});

Die Installation der beiden Pakete dauerte 7 Sekunden. Danach zeigte das Admin unter Plugins das Verzeichnis mit denselben Plugins wie auf Cloudflare.

Ich habe Post Views installiert, ein Plugin, das Seitenaufrufe zählt. Vor der Installation zeigt EmDash die Signaturprüfung und die angeforderten Rechte, auf Node.js genauso wie auf Cloudflare. Die Installation selbst dauerte 2 Sekunden.

Danach habe ich die Site für den Betrieb gebaut und mit node ./dist/server/entry.mjs gestartet. EmDash lädt das Plugin beim Start, startet workerd aus dem Projektordner, und die Routen des Plugins antworten in unter 20 Millisekunden aus der Sandbox.

Es gibt aber einen Unterschied, den du kennen solltest. Auf Cloudflare begrenzt die Sandbox jedes Plugin auf 50 Millisekunden Rechenzeit, 10 Aufrufe nach aussen und 30 Sekunden Laufzeit. Auf Node.js gilt nur die Laufzeit (Doku). Ein Plugin kann dort also nicht an deine Daten oder ins Netz, wenn es das nicht angemeldet hat, aber es kann deinen Server 30 Sekunden lang beschäftigen. Wie streng die Limits auf Cloudflare greifen, habe ich in Das Plugin-Problem gemessen.

Cloudflare als Hoster oder als Proxy davor

„Ohne Cloudflare“ kann zweierlei heissen. Viele WordPress-Sites nutzen Cloudflare, aber nur als Proxy und CDN vor dem eigenen Server: Cloudflare filtert Angriffe und liefert Bilder und Skripte aus, die Seiten selbst baut der Server. Das geht mit EmDash genauso. Für EmDash ergeben sich damit drei Varianten:

Der Proxy ändert an EmDash selbst wenig, denn EmDash merkt davon kaum etwas. Alles, was über Bindings im Worker läuft, bleibt der ersten Spalte vorbehalten. Diese Punkte gelten deshalb für beide Varianten mit eigenem Server:

• E-Mail. Ohne Mail-Plugin verschickt EmDash keine Einladungen, Login-Links und Mails zur Kontowiederherstellung, und du musst Einladungslinks von Hand weitergeben. Das offizielle Plugin für Cloudflare Email Sending braucht ein Worker-Binding. Für Node.js nennt die Doku nur das von der Community gepflegte emdash-smtp, das SMTP und Dienste wie Amazon SES, Brevo oder Postmark anbindet (Doku).
• Backups. D1 bringt Time Travel mit, also Wiederherstellungspunkte der letzten 7 oder 30 Tage, je nach Plan. Für SQLite empfiehlt die Doku den Backup-Befehl von SQLite samt anschliessender Prüfung der Kopie (Doku). Die eingebaute JSON-Sicherung im Admin läuft dagegen überall. Was welche Variante sichert, habe ich in EmDash Backup verglichen.
• Semantische Suche. Die beiden Such-Plugins aus dem Cloudflare-Paket, AI Search und Vectorize, brauchen Worker-Bindings (Quellcode). Die eingebaute Volltextsuche nutzt die Datenbank und braucht kein Binding.
• Bot-Erkennung für Bezahlinhalte. Wer mit x402 nur Bots zur Kasse bitten will, braucht EmDash auf Workers mit Bot Management (Doku). Ein Proxy davor reicht nicht, weil EmDash die Bot-Bewertung aus dem Request-Objekt von Workers liest. Fehlt sie, gibt es keinen Fehler: EmDash hält dann jeden Besucher für einen Menschen, und niemand zahlt.
• Objekt-Cache. Auf Node.js speichert EmDash Abfragen nur im Arbeitsspeicher des jeweiligen Prozesses, und mehrere Server teilen diesen Cache nicht (Doku).

Zwei Dinge macht der Proxy aber besser, und bei einem davon lauert eine Falle.

Seiten-Cache. Cloudflare speichert HTML standardmässig nicht (Cloudflare-Doku), mit einer Cache Rule aber schon. Astro schickt auf Node.js die passenden Header mit, also CDN-Cache-Control für die Dauer und Cache-Tag für das gezielte Löschen. Das habe ich im Quellcode von Astro 7.3.8 nachgesehen. Nur löscht beim Veröffentlichen niemand etwas bei Cloudflare: Astros Cache auf Node.js lebt im Arbeitsspeicher, und nur dort wird gelöscht. Ohne eigenes Skript, das die Purge-API aufruft, sehen Leser einen korrigierten Artikel erst, wenn die Cache-Dauer abgelaufen ist. Wie das Löschen auf Workers von selbst passiert, steht in Schnell und trotzdem aktuell.

IP-Adressen. Auf Workers vertraut EmDash dem Header CF-Connecting-IP von selbst. Auf Node.js tut es das nur, wenn du ihn mit trustedProxyHeaders: ["cf-connecting-ip"] freigibst. Vergisst du das, setzt EmDash die Limits für Login-Versuche aus, und alle Besucher teilen sich ein gemeinsames Limit von 20 Kommentaren in 10 Minuten (Doku). Gibst du ihn frei, muss dein Server aber wirklich nur Anfragen von Cloudflare annehmen, etwa über einen Cloudflare Tunnel oder eine Firewall, die nur die IP-Bereiche von Cloudflare durchlässt. Sonst schickt ein Angreifer den Header direkt an deinen Server, gibt sich bei jeder Anfrage eine neue Adresse und umgeht damit die Limits. Davor warnt auch die Doku. Ganz ohne Proxy gilt dasselbe für den Header deines eigenen Reverse Proxys, etwa x-real-ip.

Medien kannst du in beiden Varianten trotzdem in R2 von Cloudflare ablegen, über die S3-Schnittstelle (Doku). Cloudflare Access als Login fürs Admin beschreibt die Doku nur für Sites auf Cloudflare. Das brauchst du aber nicht: Passkeys und die anderen Login-Arten von EmDash funktionieren überall.

Die vier neuen Funktionen von 1.0

Montti nennt vier Neuerungen, die alle an Cloudflare binden. Das stimmt für zwei davon, nur gehören diese gar nicht zum CMS.

Hyperdrive. Der Adapter verbindet EmDash auf Cloudflare effizienter mit PostgreSQL. Er ist tatsächlich nur auf Workers nutzbar. Er ist aber ein Zusatz: PostgreSQL selbst unterstützt EmDash auch ohne Cloudflare über einen eigenen Adapter (Doku). Eine Einschränkung gibt es: Mit Hyperdrive laufen keine Sandbox-Plugins (Doku).

Workers Cache. Auch das ist ein Adapter für Cloudflare. Auf Node.js speichert EmDash Zwischenergebnisse im Arbeitsspeicher, und davor kannst du jeden Cache oder jedes CDN deiner Wahl setzen.

Sandbox-Container pro Projekt und Git-Verlauf über Cloudflare Artifacts. Beides gehört zu EmDash Build, dem KI-Baukasten, mit dem du eine Site im Chat beschreibst. EmDash Build ist ein eigenes Projekt und läuft laut eigener Beschreibung in einer Cloudflare Sandbox (Repository). Was es kann, hat Daniel in EmDash Build im Test ausprobiert. Hier hat Montti recht: Wer EmDash Build nutzt, nutzt Cloudflare. Das CMS selbst braucht beides nicht.

Wem gehört das Plugin-Verzeichnis?

Das Verzeichnis unter plugins.emdashcms.com betreibt das EmDash-Projekt, und es moderiert, was es anzeigt. So weit stimmt Montti. Die Frage ist, was daraus folgt.

Plugins liegen nicht in diesem Verzeichnis. Herausgeber veröffentlichen sie über das AT Protocol in ihrem eigenen Konto, und das Verzeichnis sammelt diese Veröffentlichungen nur ein. Wird ein Plugin dort ausgeblendet, bleibt die Veröffentlichung bestehen, wie Montti selbst aus der Doku zitiert. Welches Verzeichnis deine Site fragt, legst du in astro.config.mjs mit registry.aggregatorUrl fest, und mit registry: false schaltest du es ganz ab (Doku). Plugins von npm kannst du ohnehin installieren, ganz ohne Verzeichnis (Doku).

Zwei Einschränkungen gehören aber dazu. Erstens kannst du mit acceptLabelers zwar zusätzliche Moderationsdienste wählen, die Regeln des Verzeichnisses selbst aber nicht aufheben (Doku). Wer der Moderation von emdashcms.com nicht folgen will, braucht ein eigenes Verzeichnis. Zweitens ist dessen Code zwar unter MIT offen, braucht aber D1, Queues und Durable Objects, also Cloudflare (Quellcode). Ein eigenes Verzeichnis kann jeder betreiben, nur eben in einem eigenen Cloudflare-Konto.

Das ist ein echter Unterschied zum Verzeichnis von WordPress.org, wo Konto, Paket und Katalog an einer Stelle liegen. Ganz frei von Cloudflare ist es aber nicht.

Geht das alles auch mit WordPress?

Montti schreibt, alle KI-Funktionen aus der Ankündigung liessen sich schon mit WordPress umsetzen. Teilweise stimmt das. Seit WordPress 6.9 gibt es die Abilities API im Kern, und das offizielle Plugin MCP Adapter macht sie für KI-Agenten zugänglich. Es hat über 40'000 aktive Installationen und steht bei Version 0.7.0, ist also noch vor 1.0.

Der Unterschied: In EmDash ist der MCP-Server eingebaut und läuft auf jeder Site ohne Plugin, auf Node.js genauso wie auf Cloudflare. Bei WordPress brauchst du ein Plugin, das noch nicht stabil ist. Gleichwertig ist das noch nicht, aber der Abstand ist kleiner, als die Ankündigung von EmDash vermuten lässt. Ob sich ein Wechsel trotzdem lohnt, habe ich für Agenturen im Leitfaden EmDash statt WordPress abgewogen.

Was stimmt und was nicht

Und die Wertungen?

Ob Cloudflare ein Open-Source-Unternehmen ist, lässt sich nicht prüfen, das ist eine Frage der Definition. Prüfen lässt sich, was offen ist: EmDash, die Plugin-Sandbox, workerd und der Code des Verzeichnisses stehen unter freien Lizenzen. Den Vergleich mit Google kommentiere ich nicht, das ist Monttis Meinung.

Wo ich ihm zustimme: Cloudflare ist überall der Standard. Die offiziellen Vorlagen tragen Cloudflare im Namen, der Installer bietet die Sandbox nur dort an, und die strengeren Limits gibt es nur dort. Wer EmDash zum ersten Mal ausprobiert, landet fast zwangsläufig bei Cloudflare. Das ist kein Lock-in, denn du kommst jederzeit wieder raus. Es ist aber ein deutlicher Schubs in eine Richtung, und den darf man kritisieren.

Wenn du EmDash auf deinem eigenen Server betreiben willst, geht das heute, mit oder ohne Cloudflare als Proxy davor. Plane dafür ein, dass du die Sandbox und den Mailversand selbst einrichtest, Backups selbst organisierst und den Server dauerhaft laufen lässt, und dass Plugins dort weniger streng begrenzt sind. Mit Cloudflare als Proxy gewinnst du den Schutz vor Angriffen und auf Wunsch den Seiten-Cache, musst dann aber trustedProxyHeaders richtig setzen, den Server gegen direkte Zugriffe abschotten und das Löschen des Caches selbst bauen. Wenn du EmDash erst kennenlernen willst, fang mit dem Einstieg in EmDash an.