EmDash CMS Review: 6 Monate später, nach dem 1.0-Release

Hinweis: Dieser Artikel enthält Referral-/Affiliate-Links. Wenn du darüber kaufst, erhalte ich möglicherweise eine Provision – ohne zusätzliche Kosten für dich.

Dieses EmDash-CMS-Review wird sechs Monate geschrieben, nachdem Cloudflares WordPress-Nachfolger am 1. April 2026 geshipt wurde, und Tage nach dem 1.0-Release. Jede unabhängige Einschätzung, die du gerade findest, ist ein April-Ersteindruck einer 0.x-Beta. Diese Beta ist weg. [email protected] ist live auf npm, die Plugin-Registry steht, und der Cloudflare-Blog selbst läuft seit dem 12. August auf EmDash.

Wenn du „was ist EmDash CMS” googelst und ob es produktionsreif ist, die kurze Version: Es ist jetzt ein echtes CMS, mit Produktions-Beweis in einem Ausmaß, das fast nichts anderes in diesem Markt vorweisen kann, und einem wirklich neuartigen Plugin-Sicherheitsmodell. Es ist außerdem immer noch Astro-only, du besitzt die Datenbank, und die Admin-UX ist jung. Ob dieser Trade für dich funktioniert, hängt von einer Weggabelung ab, und dieses Review läuft sie Ende zu Ende: Cloudflare all-in (Workers + D1 + R2) gegen Self-Hosted-Node.js auf einem günstigen VPS mit SQLite und S3-Backups.

Was folgt, ist die Ops-Tiefe, die kein April-Artikel hatte: echte Deploy-Configs, Kostenrechnung in Größenordnungen, die Failure Modes aus EmDashs eigenen Troubleshooting-Docs und ein Fazit pro Persona. Alle Metriken sind datiert „Stand September 2026”, damit du sie zum Publish-Zeitpunkt gegenprüfen kannst.

Was ist EmDash CMS? Cloudflares WordPress-Nachfolger, erklärt

EmDash ist ein Full-Stack-TypeScript-CMS, gebaut als Astro-Integration. MIT-lizenziert, kein WordPress-Code, angekündigt am 1. April 2026 als „spiritual successor to WordPress” und Ende September 2026 als [email protected] geshipt. Ein Deployment trägt die Astro-Site, das Admin-Panel, eine REST-API, Passkey-first-Auth, eine Media Library und ein Plugin-System. Das ist der ganze Punkt: CMS plus Website in einer Anwendung.

Die Architektur zählt mehr als die Feature-Liste:

• Astro-Integration, konfiguriert in astro.config.mjs als emdash({ database, storage, sandboxRunner }). Die Peer-Dependency ist astro >= 6.
• Live Content Collections: Server-gerenderte Seiten lesen veröffentlichte Inhalte zur Request-Zeit. Die Änderung eines Redakteurs taucht beim nächsten Request ohne Rebuild auf. Prerendered Pages bleiben statisch, bis du neu buildst.
• Inhalte leben in der Datenbank, nicht in deinem Repo. Redakteure arbeiten im Admin unter /_emdash/admin; Entwickler fahren npx emdash types, um TypeScript-Deklarationen zu generieren (emdash-env.d.ts aktualisiert sich in Dev selbst).
• Portable-Text-Inhaltsformat (strukturiertes JSON, kein serialisiertes HTML). TipTap ist der Rich-Text-Editor. Es gibt einen gutenberg-to-portable-text-Konverter für WordPress-Importe.
• Kysely-SQL-Adapter: D1, SQLite, libSQL oder Postgres. Medien gehen nach R2, jede S3-API oder lokale Disk.
• MCP-Server in jedem Install eingebaut unter /_emdash/api/mcp, mit rund 60 Tools (Content-CRUD, Publish, Schedule, Media, Schema, Taxonomies) plus Plugin-Tools. Nur Bearer-Token-Auth: OAuth 2.1 mit PKCE, Personal Access Tokens oder emdash login Device Grant. Seit 0.37.0 erfordern Updates den _rev-Concurrency-Token, sodass ein Agent nicht blind über die Änderungen eines Redakteurs schreiben kann.
• x402-Payments eingebaut: Inhalt als paid markieren, Preis und Wallet-Adresse setzen, und Agents bekommen HTTP 402, zahlen und lesen. Interessantes Primitive, kein Revenue-Plan (echtes x402-Volumen lag im April immer noch bei rund 28k $/Tag ökosystemweit).
• Fünf Templates zur create-emdash-Zeit, jedes mit einer Cloudflare- und einer Node/SQLite-Variante: blog, marketing, portfolio, starter und blank.

Node.js >= 22.16 ist Pflicht, wenn du selbst hostest. Und eine Sache, die die Docs unverblümt sagen: EmDash ist kein visueller Page Builder. Astro-Komponenten besitzen das HTML. Wenn du Drag-and-Drop-Layout willst, ist das nicht dein Tool.

EmDash-CMS-Architektur: Astro-Site mit Admin-Panel, REST-API und MCP-Server, die eine Datenbank und S3-kompatiblen Medien-Storage abfragen

Diese React-Abhängigkeit kauft dir den Admin unten: den EmDash-v1.0-Post-Editor, über die offizielle Site.

EmDash-v1.0-Admin-Interface: der Post-Editor mit Sidebar-Navigation, TipTap-Content-Bereich und einem Publish-Panel, das Live-Version gegen Draft-Änderungen trackt

Wenn du das mit dem SaaS-Feld vergleichst, ist unser Beitrag zu den besten Headless-CMS-Optionen für Astro der richtige Ort, um zu sehen, wo ein DB-gestütztes In-App-CMS gegenüber git-basierten und gehosteten Alternativen steht. Für Build-Speed-Kontext zum darunterliegenden Framework sieh was Astro 7 für die Build-Geschwindigkeit geändert hat (EmDash 1.0.1 trackt Astro 7 schon in seinen devDependencies).

Sechs-Monate-Check: 12,9k Sterne, 126k Downloads und eine große Migration

April-Reviews bewerteten eine 0.1-Preview. Sechs Monate Shipping später, hier der Projektgesundheits-Snapshot, Stand Ende September 2026:

Die Releases waren changesets-getrieben und signiert, mit npm Provenance via GitHub-Actions-OIDC-Trusted-Publishing und SLSA-Attestierungen auf 1.0.1. Das ist ernste Supply-Chain-Hygiene für ein CMS-Projekt von einem halben Jahr. Die Kadenz ist auch echt: 0.19.0 landete im August (das Release, das Scheduled Publishing endlich zum Laufen brachte), 0.37.0 am 9. September brachte Registry-Verifizierung und die _rev-Concurrency-Anforderung, und 1.0.1 kam Ende September. Maintainer sind Matt Kane (das author-Feld auf npm) und Noah Pham, der vom Intern zum zweiten Maintainer mit 80-plus Changesets wurde, plus Cloudflare-Staff in der Contributor-Liste. Sechs Monate drin ist das kein Ein-Personen-Repo.

Dann gibt es Kunde null. Der Cloudflare-Blog migrierte am 12. August 2026 zu EmDash, und die Zahlen sind der stärkste Produktions-Beweis in diesem Markt das ganze Jahr:

• ~75 RPS Baseline, Spitzen über 5.000 RPS, bis zu 850 RPS im Steady State serviert.
• k6-Load-Testing mit Ramp-, Breakpoint- und 7.000-RPS-Burst-Profilen. Schwellen: unter 0,01 % 5xx, P95 unter 500ms, P99 unter 1s.
• ~70 % aller Requests aus dem Cache serviert (99,5 % der statischen Dateien), mit flacher p95-Latenz, wo die Legacy-Plattform spiky war.
• Agents-Week-Stress: 28 Posts in 9 Tagen, ~3M Pageviews, 450 RPS sustained. Eine 28.000-RPS-DDoS wurde am 10. August am Cloudflare-Edge absorbiert, nicht von EmDash.
• Der Rollout war ein Proxy-Worker mit Version-Cookie, 1 % auf 5 % auf 15 % auf 100 % an einem Tag, mit Auto-Fallback auf den Legacy-Blog bei 500ern.

Zwei ehrliche Einschränkungen. Erstens: Ihr Stack ist kein normaler Deploy — Workers Cache, ein EmDash-Object-Cache auf Workers KV und Hyperdrive zu PlanetScale. Sie nutzten Postgres/MySQL via Hyperdrive, nicht D1. Dein Blog wird das nicht brauchen. Zweitens: Scheduled Publishing funktionierte bis v0.19.0 überhaupt nicht, eine Lücke, die Cloudflare mitten in der Migration entdeckte. Das ist die Art Bug, die nur auftaucht, wenn jemand sein eigenes Hundefutter frisst, und sie ist es wert, sich zu merken, wenn Leute sagen „1.0 heißt ausgereift”.

Cloudflares Migrations-Post veröffentlichte außerdem ihre eigene Editor-Bug-Liste: Custom-HTML-Blöcke waren im Block-Picker schwer zu finden, die Formatierungs-Toolbar scrollte bei langen Posts weg, In-Entity-Editor-Bugs und die Scheduled-Post-Probleme oben. Das sind keine Third-Party-Schmähungen. Das ist der Vendor, der seine eigenen Papercuts öffentlich loggt — für dich als Käufer nützlicher als jede Feature-Matrix.

EmDash 1.0 und die Plugin-Registry: was geshipt wurde

Zwischen Aprils Beta und Ende-September-1.0 ist die Headline-Änderung eine dezentrale Plugin-Registry, gebaut auf AT Protocol, demselben Protokoll, das Bluesky antreibt. Publisher behalten Ownership, Identität und Release-History in ihren eigenen signierten Records (Merkle Search Trees mit Inclusion Proofs). EmDash fährt einen Default-Katalog, einen Aggregator und einen Workers-AI-Labeler für Moderation, alles Open Source. Das heißt: Keine einzelne Firma kann die History eines Plugins still umschreiben oder einem Publisher die Identität wegnehmen. Wenn der Aggregator-Record und der eigene Record des Publishers auseinanderlaufen, flaggt EmDash es (AGGREGATOR_RECORD_MISMATCH kam in 0.37.0), statt mit den Schultern zu zucken.

Install-Time-Verifizierung ist, wo es interessant wird. EmDash prüft Checksums (base32-Multibase-sha2-256, Pflicht seit 0.37.0), Paketnamen, Version und Capability-Manifest-Identität. Optionale Sigstore- und SLSA-Provenance wird verifiziert, wenn vorhanden. Delegated Releases laufen über GitHub OIDC mit Workflow-Pinning via releases.emdashcms.com, und Publisher-Onboarding nutzt einen Browser-Approval-Schritt. Stell dir den Install-Dialog wie den Berechtigungs-Prompt eines Mobile-App-Stores vor: Du siehst, was das Plugin kann, bevor du es genehmigst.

Das Ökosystem bei 1.0 ist klein, aber nicht mehr leer: Lexington Themes shippt 44 Astro-Themes mit EmDash-Varianten, Urumi ist das erste eCommerce-Plugin, und Empress zielt auf Multi-Brand-Flotten. Bezahlte Plugins sind noch nicht in der Registry (Cloudflare schaut dafür auf Atproto Spaces Alpha). Und eine Einschränkung, die ich für dich nicht auflösen kann: Die exakte Zahl installierbarer sandboxed Plugins im Katalog gerade jetzt braucht einen Live-Check im Admin. Auf diese Zahl steht und fällt das Ökosystem-Argument. Alles andere in 1.0 ist die langweilige Art von Reife: der WordPress-Importer (WXR, REST-API, WordPress.com via ein EmDash-Exporter-Plugin mit Application Passwords), Lokalisierung mit Übersetzungsgruppen, Revisions, Drafts, Trash, FTS5-Suche, Audit-Log und das Agent-Tooling (MCP, npx emdash types, Agent-Skills).

Sandboxed Plugins und Capability-Manifeste

EmDash hat zwei Plugin-Formate. Native Plugins gehen in plugins: [] und laufen in-process mit vollem Host-Zugriff. Das ist für First-Party- oder voll vertrauten Code: Forms, Embeds, SEO, Audit-Log, Cloudflare-E-Mail.

Sandboxed Plugins sind die interessanten. Sie werden in sandboxed: [] deklariert oder aus der Registry installiert, und sie shippen ein Capability-Manifest wie capabilities: ["content:read", "email:send"]. Der Admin genehmigt diese Capabilities bei der Installation. Das eigene Beispiel der Docs ist die richtige Denkweise: Ein Plugin, das Artikel für die Suche indexiert, kann Inhalte lesen und einen Search-Service aufrufen und kann keine Artikel editieren oder andere Hosts kontaktieren. Hooks wie content:afterSave laufen in einer isolierten Runtime nur mit privatem Storage und ohne Netzwerkzugriff, es sei denn, exakte Hostnames wurden deklariert.

Die Durchsetzung ist physisch, nicht auf Ehrenwort. Auf Cloudflare ist jedes Plugin ein Dynamic Worker via Worker Loader. Auf Node.js ist es ein workerd-Kindprozess, Cloudflares eigene Runtime, die auf deiner Box läuft. Limits sind fixiert ohne Config-Knob: 50ms CPU und 10 Subrequests (nur Cloudflare), 128MB Memory, 30s Wall Time auf beiden. Ein Hook-Timeout wird geloggt, und der Request läuft ohne das Plugin weiter. Ein Route-Timeout lässt den Aufrufer fehlschlagen.

sandbox: false lässt sandboxed Plugins in-process laufen. Nur zum Debuggen. Es verweigert den Start auf Cloudflare Workers.

EmDash Build: der AI-Site-Builder in Alpha

EmDash Build ist ein Open-Source-Alpha-AI-Site-Builder (Demo auf build.emdashcms.com): ein Cloudflare-Sandbox-Container pro Projekt, das Agents SDK, Änderungen getrackt als Git-Commits, Publishing in Workers for Platforms. Beobachte es. Bau noch keine Kundenarbeit darauf.

Für wen EmDash ist (und wann die eigenen Docs raten, etwas anderes zu wählen)

Credit, wo Credit gebührt: EmDashs Docs sind ungewöhnlich ehrlich darüber, wer das nicht nutzen sollte. Die „good fit”-Checkliste verlangt, dass alle vier dieser Punkte zutreffen:

Wenn du nicht alle vier abhaken kannst, hör hier auf. Die „reasons to choose another approach” der Docs sind fast wörtlich: Das Projekt ist nicht Astro; alle Inhalte müssen im Source-Repo bleiben; mehrere unabhängige Frontends brauchen ein CMS, das unabhängig deployt; oder du willst die Ops-Last nicht. Der letzte Punkt steht dort in klaren Worten: Das Team ist verantwortlich für die Datenbank, Medien-Storage, Backups, Upgrades und die Anwendung, die das Admin-Panel serviert.

Das greift dem Einwand Nummer eins auf Reddit vor („you need to manage a database to use it”). Ja. Musst du. Die Docs stimmen zu und sagen git-basierten CMS-Usern, sie sollen dateibasierte Collections nutzen.

Die eigene Vergleichstabelle der Docs lohnt sich, für dein Entscheidungsmeeting zu klauen:

EmDash vs. WordPress: was die April-Kritiker richtig und falsch lagen

Die April-Takes sind interessant gealtert. Hier die Abrechnung, nochmal gegen sechs Monate Evidenz gehalten.

Zum Kontext, wogegen EmDash antritt: WordPress betreibt immer noch einen riesigen Teil des Webs, mit 60k+ Plugins und einem Theme-Markt, den 2026 niemand matcht. Cloudflares Launch-Winkel war Security und Architektur: Es zitierte, dass 96 % der Sicherheitsprobleme von WordPress-Sites aus Plugins stammen, und positionierte sandboxed Plugins plus Passkeys als Antwort. Die Community-Reaktion spaltete sich entlang vorhersehbarer Linien. Die WordPress-Crowd auf Reddit nannte es ein „vibe coded CMS that barely works” und notierte das Ökosystem-Catch-22 (in einem Thread sagte jemand, sein Team hätte es gedemot und ein „hard no” gegeben). Die Astro-Crowd war interessiert. Beide bewerteten eine Beta.

Die Lock-in-Frage verdient eine gerade Antwort, da Mullenweg sie aufwarf. EmDash ist MIT. Die Adapter sind portabel: D1, SQLite, libSQL, Postgres, R2, jede S3-API, lokale Disk. Die Node-Deploy-Docs sind nicht Cloudflare-first. Das Lock-in-Risiko ist Gravitation (Ökosystem, Feinschliff, wer Bugs am schnellsten fixt), nicht Lizenzierung. Mullenweg schrieb außerdem „I’d be surprised if this doesn’t get tens of thousands of sites on it”; WPJohnny sagte, die Bedrohung sei „almost zero”. Sechs Monate Downloaddaten liegen zwischen diesen beiden Claims. Und auf der WordPress-Seite des Zauns ist genau das die Kosten- und Ops-Rechnung, für die unser Astro-vs.-WordPress-Kosten-und-Ops-Breakdown da ist.

Noch ein WordPress-Vergleich, der zählt, wenn du migrierst: Der Importer ist real, aber begrenzt. Posts, Pages, Media, Taxonomies und Custom Post Types kommen rüber (CPTs mappen auf Collections, Gutenberg-Inhalte konvertieren zu Portable Text). Dein Theme kommt nicht rüber. Custom-Plugin-Verhalten kommt nicht rüber. Die Docs sagen das unverblümt. Budgetiere einen Rebuild der Präsentationsschicht, nicht nur ein Export-Import.

EmDash deployen: Cloudflare Workers vs. Self-Hosted auf einem VPS

Beide Deploy-Pfade sind offiziell dokumentiert, und beide shippen Admin plus API plus MCP als eine Einheit. Das Operator-Framing ist einfach. Der Cloudflare-Pfad ist die wenigsten Server und die meiste Plattform-Kopplung, mit sandboxed Plugins hinter Workers Paid gated. Der VPS-Pfad ist langweilige Ownership: Datenbank, Backups und Upgrades gehören dir, auf einer Box, die du kontrollierst. Unten beide, mit den Configs, die du brauchst.

EmDash-CMS-Deploy-Pfade im Vergleich: Cloudflare Workers mit D1 und R2 gegenüber Self-Hosted-Node.js mit SQLite und S3-Backups auf einem VPS

Der Cloudflare-Pfad: Workers + D1 + R2 (und wo Workers Paid Pflicht ist)

Schnellster Happy Path: den „Deploy to Cloudflare”-Button auf dem blog-cloudflare-Template im emdash-cms/templates-Repo drücken (das volle Set ist blog, marketing, portfolio, starter und blank, jedes mit einer Cloudflare- und einer Node-Variante). Wrangler legt die D1-Datenbank und den R2-Bucket beim ersten Deploy an, und Migrationen werden beim ersten Request automatisch im Default-auto-Modus angewendet. Templates lassen das Worker-Loader-Binding auskommentiert, weshalb neue Projekte per Default auf dem Free Plan deployen.

Wenn du es selbst verdrahtest, sehen die Essentials so aus:

// wrangler.jsonc (essentials)
{
  "name": "my-emdash-site",
  "main": "./src/worker.ts",
  "compatibility_date": "2026-02-24",
  "compatibility_flags": ["nodejs_compat"],
  "d1_databases": [{ "binding": "DB", "database_name": "my-emdash-site" }],
  "r2_buckets": [{ "binding": "MEDIA", "bucket_name": "my-emdash-media" }],
  "worker_loaders": [{ "binding": "LOADER" }],   // only for sandboxed plugins (Workers Paid)
  "triggers": { "crons": ["* * * * *"] },        // publishing, plugin tasks, backups, maintenance
  "placement": { "mode": "targeted", "region": "..." } // near the D1 primary
}

// astro.config.mjs (Cloudflare)
import cloudflare from "@astrojs/cloudflare";
import react from "@astrojs/react";                 // REQUIRED - admin UI is React
import emdash from "emdash/astro";
import { d1, r2, sandbox, kvCache } from "@emdash-cms/cloudflare";

export default defineConfig({
  output: "server",
  adapter: cloudflare(),
  integrations: [react(), emdash({
    database: d1({ binding: "DB" }),
    storage: r2({ binding: "MEDIA" }),
    sandboxRunner: sandbox(),                 // omit + drop LOADER to stay on the free plan
    objectCache: kvCache({ binding: "CACHE" }) // optional KV object cache
  })]
});

// src/worker.ts
import handler, { createScheduledHandler, PluginBridge } from "@emdash-cms/cloudflare/worker";
export { PluginBridge };
export default { ...handler, scheduled: createScheduledHandler() } satisfies ExportedHandler;

Deploye mit pnpm build && pnpm wrangler deploy. Cloudflare-spezifische Extras in einem Durchgang: Targeted Placement nahe dem D1-Primary (nicht mit D1-Read-Replicas kombinieren, und session auf seinem Default "disabled" lassen), Workers Cache via den cacheCloudflare()-Provider mit routeRules, Image-Transforms über das IMAGES-Binding (abgerechnet als Cloudflare Images: 5.000 unique Transformations/Monat gratis auf dem Free Plan, danach schlagen neue mit Fehler 9422 fehl), Cloudflare-Access-SSO mit Role Mapping (Secret via wrangler secret put CF_ACCESS_AUDIENCE) und E-Mail via das Cloudflare-Email-Plugin mit einem send_email-Binding. Der letzte Punkt zählt: Magic Links und Einladungen schlagen mit „Email is not configured” fehl, bis du es eingerichtet hast, und passwordless Auth ist der Default-Flow.

Verifiziere, bevor du es fertig nennst:

1. pnpm wrangler tail und bestätige, dass der Scheduled Handler tickt (der * * * * *-Cron).
2. Öffne /_emdash/admin, log dich ein und prüfe, dass das Dashboard lädt.
3. Veröffentliche einen Draft und bestätige, dass die öffentliche Seite beim nächsten Request aktualisiert.

Wenn du allgemein auf Workers baust (mehr als nur EmDash), deckt unser Guide zu Self-Hosted-Apps auf Cloudflare Workers die Plattform-Muster ab, auf denen dieser Stack sitzt.

EmDash auf Node.js selbst hosten: SQLite, Docker und S3-Backups

Das ist der Bitdoze-Home-Turf-Pfad: Node.js standalone, SQLite auf einem Volume, S3-kompatible Medien, Docker und deine normale Backup-Routine. Jede Hetzner-Klasse-Box im Bereich 4 bis 5 Euro im Monat fährt eine EmDash-Site auf Blog-Niveau komfortabel. Das ist in der Praxis ein Hetzner-Cloud-VPS, oder eine Budget-KVM-Box wie Hostinger VPS, wenn du andere Regionen willst oder deren Panel bevorzugst.

Was du zuerst brauchst:

Die Node-Config ist kürzer als die Cloudflare-Variante:

// astro.config.mjs (Node.js)
import node from "@astrojs/node";
import emdash, { local, s3 } from "emdash/astro";
import { sqlite } from "emdash/db";   // also: libsql, postgres adapters

export default defineConfig({
  output: "server",
  adapter: node({ mode: "standalone" }),
  integrations: [emdash({
    database: sqlite({ url: `file:${process.env.DATABASE_PATH}` }),
    storage: local({ directory: "./data/uploads", baseUrl: "/_emdash/api/media/file" }),
    // storage: s3() for S3-compatible media (R2, AWS S3, any S3 API)
    sandboxRunner: "@emdash-cms/sandbox-workerd/sandbox" // needs @emdash-cms/sandbox-workerd + workerd
  })]
});

Fahr es mit node --env-file=.env ./dist/server/entry.mjs (Port 4321 per Default, HOST- und PORT-Env-Vars werden beachtet). Der Standalone-Entry lädt .env nicht automatisch. --env-file zu vergessen ist der häufigste First-Run-Fehler hier.

Die offiziellen Docs shippen ein Dockerfile und docker-compose.yaml (node:22-alpine Multi-Stage, Named Volume für /app/data), das direkt in ein Dokploy-artiges Deploy fällt. Auf die Essentials angepasst sieht die Compose-Seite so aus:

# adapted from the official docs.emdashcms.com/deployment/nodejs/ compose file
services:
  emdash:
    build: .
    ports:
      - "4321:4321"
    env_file: .env
    volumes:
      - emdash-data:/app/data   # SQLite db + local uploads live here
    restart: unless-stopped

volumes:
  emdash-data:

Eine Docker-Falle: workerd ist eine plattformspezifische Binary, die via optional Dependencies installiert wird. Installiere sie in Multi-Stage-Builds auf derselben Plattform wie die Runtime-Stage mit optional Deps an, dann verifiziere:

./node_modules/.bin/workerd --version

Env-Variablen, die man kennen sollte: DATABASE_PATH, HOST, PORT, S3_ENDPOINT, S3_BUCKET, S3_ACCESS_KEY_ID, S3_SECRET_ACCESS_KEY, S3_REGION, S3_PUBLIC_URL, EMDASH_ENCRYPTION_KEY und optional EMDASH_PREVIEW_SECRET, EMDASH_AUTH_SECRET, EMDASH_IP_SALT, EMDASH_WORKERD_PASSTHROUGH_ENV. Lies Secrets niemals aus import.meta.env; Vite inlined sie zur Build-Zeit ins Client-Bundle.

Backup-Lage: Halte SQLite auf einem Named Volume, Medien auf S3, und denk dran, dass automatische JSON-Snapshots unter backups/ im selben Storage-Backend leben. Stoppe den Prozess, bevor du die DB-Datei ersetzt — das ist die eigene Restore-Prozedur der Docs. Halte eine Recovery-Kopie von EMDASH_ENCRYPTION_KEY außerhalb deiner Datenbank-Backups, sonst sind wiederhergestellte Plugin-Einstellungen unlesbar. Rollback ist das, was dein Volume-Snapshot plus Key-Kopie hergibt; es gibt kein EmDash-natives Point-in-Time-Recovery, das dich rettet.

Für Panel-basierte Ops statt rohem systemd kannst du Node.js-Apps auf CloudPanel hosten (wir fahren dort Strapi 5), oder folge wie man Astro auf einem VPS mit CloudPanel deployt, sobald das CMS selbst läuft. Wenn du eine One-Click-Docker-Compose-Route willst, passt Coolify, die Self-Hosted-PaaS, und Coolify vs. Dokploy vs. Kamal im Vergleich ist das Pick-the-Tool-Stück. Für die Medienseite deckt S3-kompatiblen Storage auf einem VPS mounten die Bucket-as-Filesystem-Optionen ab.

Verify-Block, der Reihe nach, bevor du DNS darauf zeigst:

1. npx emdash migrate --check meldet clean.
2. Eine öffentliche Seite liefert 200 mit erwartetem Inhalt.
3. Du kannst dich unter /_emdash/admin einloggen.
4. Media-Upload-, Retrieve- und Delete-Roundtrip funktioniert.
5. Ein Draft publisht und die öffentliche Seite aktualisiert.
6. Ein Sandboxed-Plugin-Aufruf funktioniert (falls du welche nutzt).
7. Scheduler-Ticks tauchen in den Prozess-Logs auf.

Kostenrechnung: Free-Tier-Workers vs. ein 4-Euro-VPS

Größenordnungen, Stand September 2026. Behandle sie nicht als Angebote.

Zwei Notizen, die die Tabelle versteckt. Das Paket ist schwer: 23 MB unpacked und 2.489 Dateien, Worker-Cold-Starts und Container-Image-Größen sind also nicht trivial. Und der Cloudflare-Blog brauchte KV-Object-Cache plus Hyperdrive plus Workers Cache, um seine Zahlen zu erreichen. Normale Sites werden das nicht.

Eine dritte Notiz, da Free-Tier-Ökonomie die übliche Frage ist: EmDash ist server-gerendert, jeder ungecachte Page-Hit macht also D1-Roundtrips. Ein Low-Traffic-Blog sitzt komfortabel innerhalb der Gratis-Kontingente. Eine vielbesuchte Marketing-Site sollte Requests modellieren, statt anzunehmen, „scales to zero” heiße gratis. Der Cloudflare-Blog erreichte ~70 % Cache-Abdeckung erst nach dem Hinzufügen der Workers-Cache-Schicht; deine Defaults werden niedriger liegen.

Wenn du Daten willst, bevor du dich auf eine Box festlegst, ist wie man Cloud-Server vor dem Commitment benchmarkt der YABS-Workflow, den ich nutze.

Ops-Fallen, auf die du stoßen wirst

Das ist die Troubleshooting-Schicht, die kein April-Review hatte. Alles unten kommt aus EmDashs eigenen Deployment- und Troubleshooting-Docs plus dem Migrations-Post-Mortem. Die Docs sind ehrlich darüber. Der Failure Mode sind Operatoren, die sie nicht lesen.

workerd auf Node: Crash-Loops und das 10-Sekunden-Startup-Fenster

Auf Node.js laufen sandboxed Plugins in Cloudflares workerd-Runtime als Kindprozess. Das ist ein echter Prozess mit echter Crash-Semantik. Der Start muss innerhalb von 10 Sekunden antworten. Ein unerwarteter Exit triggert einen Restart mit 1-bis-30-Sekunden-doubling-Backoff. Und hier die scharfe Kante: 5 Crashes in 60 Sekunden und der Runner gibt auf, bis du den Server neu startest. Die Logzeile ist unverblümt: „workerd crashed 5 times in 60 seconds, giving up.” Jeder sandboxed Hook und jede Route schlägt von da an fehl, während die Site weiterserviert.

Der Kindprozess bekommt außerdem eine abgespeckte Umgebung: nur PATH, HOME, TMPDIR, TMP, TEMP, LANG, LC_ALL. Secrets lecken nicht in die Sandbox. Erweitere sie mit EMDASH_WORKERD_PASSTHROUGH_ENV, wenn ein Plugin wirklich mehr braucht.

Wenn Sandboxed-Plugin-Features tot wirken, während die Site weiterserviert, hat der workerd-Crash-Loop seine Retries erschöpft. Starte den App-Prozess neu, dann prüfe ./node_modules/.bin/workerd --version und bestätige, dass die Binary zu deiner Container-Plattform passt. Wenn die Sandbox stattdessen beim Start innerhalb von Docker crasht, wurde die workerd-Binary wahrscheinlich für die falsche Plattform gebaut: Ein Multi-Stage-Build installierte sie auf der Plattform des Builders. Reinstalliere sie mit optional Deps an auf der Plattform der Runtime-Stage.

EMDASH_ENCRYPTION_KEY-Rotation und Backup-Fallen

Setze EMDASH_ENCRYPTION_KEY, bevor du das erste Plugin-Secret speicherst. Generiere es mit npx emdash secrets generate. Halte eine Recovery-Kopie außerhalb deiner D1- oder SQLite-Backups, weil ein Restore der Datenbank ohne den Key Plugin-Einstellungen unlesbar lässt.

Rotation ist manuell und leicht gruselig: generiere einen neuen Key, halte die alten Keys komma-separiert gelistet, bis jedes Plugin-Secret unter dem neuen Key neu gespeichert wurde, dann lass die alten fallen. EmDash meldet nicht, welche Key-IDs noch in Benutzung sind. Das ist eine dokumentierte Lücke, kein Bug, den du dir einbildest.

Workers Cache serviert eingeloggten Redakteuren stale Pages

Responses ohne expliziten Cache-Control-Header werden über die RFC-9111-Heuristik grob 2 Stunden gecacht. Setze explizite Header auf jeder Custom Route: private, no-store für alles Session-abhängige.

Wenn du Edge-Caching ohne Workers Cache willst, können Self-Hoster Statisches und Medien mit einem CDN wie Bunny.net fronten und Origin-Caching explizit halten.

Warum der Health-Endpoint lügt

Die Docs schlagen vor, src/pages/health.ts mit einem 200 hinzuzufügen. Mach es, aber verstehe das Limit: Ein 200 beweist nur, dass Astro Requests serviert. Datenbankgesundheit, Storage-Gesundheit, Migrationen und die Sandbox sind nicht abgedeckt. Die Docs sagen das explizit.

Mehr Fallen, die man kennen sollte

Pros und Cons nach 1.0

Worauf läuft dieses EmDash-CMS-Review also hinaus? Acht gepaarte Tradeoffs. Lies die rechte Spalte zweimal, bevor du dich festlegst; dort wohnt die Betriebskosten.

Fazit: Wer EmDash nutzen sollte (und wer nicht)

Entscheidungsflussdiagramm für die EmDash-CMS-Adoption: Astro-Anforderung, Redakteurs-Bedürfnisse, Bereitschaft zu Datenbank-Ops und Cloudflare-vs.-VPS-Deploy-Wahl

Agentur. Die glaubwürdigste neue Plattform-Build-Wette seit Jahren: Templates für die Übergabe, sandboxed Plugins als Support-Blast-Radius-Kontrolle, Workers for Platforms und EmDash Build als White-Label-Site-Maschinerie. Aber wähl es für neue Astro-Builds, bei denen du das Theme kontrollierst, nicht für Kunden, die den WordPress-Plugin-Store verlangen. Beobachte die Registry auf Paid Plugins; sie sind noch nicht da. Bedingtes Ja.

Astro-Entwickler. Wenn du schon ein datenbankgestütztes CMS auf Astro wolltest, ist das der offensichtliche Default gegenüber einem angedockten SaaS-Headless-CMS. npx emdash types plus MCP machen es agent-freundlich, und der Node-+-SQLite-Pfad heißt, Cloudflare ist optional. Wenn du ein Content-in-git-Loyalist bist, wechsle nicht; die Docs stimmen dir zu. Ja, mit diesem Vorbehalt.

WordPress-Flüchtling. Der Importpfad ist real: WXR, REST-API oder WordPress.com via das EmDash-Exporter-Plugin mit einem Application Password. Custom Post Types mappen auf Collections, Gutenberg konvertiert zu Portable Text. Passkeys plus RBAC sind ein Security-Upgrade. Aber das Theme und jedes ernsthafte Plugin-Verhalten sind ein Rebuild, der Editor ist TipTap statt Gutenberg, und du akzeptierst Datenbank-Ops. Migriere zuerst eine Low-Stakes-Site. Avulux zog eine Microsite in unter einem Tag mit Agent Skills um; deine 40-Plugin-Site wird das nicht sein. Wenn du entscheidest, dass sich der Rebuild nicht lohnt und auf WordPress bleibst, kannst du die Ops-Seite zumindest an Managed Cloud Hosting wie Cloudways auslagern. Bedingt.

Solo-Blogger. Der ehrliche Vergleich ist EmDash gegen Markdown-in-git. Wenn du nur publishst, bleibt statisches Astro plus Markdown einfacher und billiger: keine Datenbank, kein Admin, kein workerd. EmDash verdient seinen Platz in dem Moment, wo du eine Admin-UI, Scheduled Posts, Media-Management oder Nicht-Dev-Co-Editoren willst. Der free-ish-Cloudflare-Deploy (ohne sandboxed Plugins) oder ein 4-Euro-VPS hält es billig. Ja, aber erst ab dieser Schwelle.

Wohin es geht: EmDash Build Richtung GA, Paid Plugins via Atproto Spaces Alpha, weiter reifender Editor und was immer WordPress als Nächstes tut. Das Fazit dieses EmDash-CMS-Reviews: Empfohlen für Astro-Teams, die ein echtes CMS wollen und bereit sind, eine Datenbank zu besitzen. Noch kein WordPress-Ersatz für Plugin-abhängige Sites. Das ist eine viel bessere Position als die, die es im April hatte.

EmDash-CMS-FAQ

Das ist ein Snapshot. Zur Drei-Monats-Marke werde ich die Kataloggröße der Registry, Paid-Plugin-Verfügbarkeit, Editor-Fixes von Cloudflares eigener Migrations-Bug-Liste und ob Templates Astro 7 pinnen nochmal prüfen. Bis dahin decken die internen Links oben die breiteren Entscheidungen ab: CMS-Wahl für Astro, Astro-vs.-WordPress-Ökonomie und die Self-Hosting-Pfade auf Workers wie auf VPS.