FAQ zu Cloudflare-Free-Plan-Limits für Emdash CMS

Was im Free-Plan noch funktioniert, was nicht, und wie Sie Emdash CMS ohne kostenpflichtige Dynamic-Workers-Features sicher ausliefern.

In Claude öffnen In ChatGPT öffnen

Auf X teilen Auf LinkedIn teilen Auf Reddit teilen

Veröffentlicht am 2026-04-08 von Emdash Cms Everything

Was begrenzt der Cloudflare-Free-Plan bei Emdash CMS?

Kern-CMS-Workflows bleiben verfügbar, die sandboxed Plugin-Ausführung jedoch nicht.
Praktisch: Content-Management und normales Site-Deployment funktionieren, die Plugin-Isolation über Dynamic Workers nicht.

Soll `worker_loaders` in der Config bleiben?

Nein. Im Free-Plan entfernen.
Wenn es drin bleibt, führt das oft zu Deploy-/Laufzeitfehlern, weil kostenpflichtige Fähigkeiten vorausgesetzt werden.

Kann ich im Free-Plan trotzdem produktiv gehen?

Ja, mit klaren Grenzen:

geeignet für Content-, Doku- und Marketing-Sites
ungeeignet, wenn Ihr Kernworkflow von sandboxed Third-Party-Plugins abhängt

Wenn sandboxed Plugin-Ausführung nicht mission-kritisch ist, reicht der Free-Tier meist zum Start.

Wie sollte Plugin-Nutzung im Free-Plan sicher gehandhabt werden?

Vertrauenswürdige-Plugins-Politik:

Plugins mit nachvollziehbarer Ownership aktivieren
Abhängigkeiten und Berechtigungen vor Release prüfen
Hochriskante Integrationslogik in isolierte Backend-Services auslagern

Free-Tier heißt nicht „keine Plugins“, sondern „keine isolierte Runtime für nicht vertrauenswürdige Plugins“.

Warum kann Deployment klappen, Plugin-Features aber trotzdem scheitern?

Weil „deploybar“ und „sandbox-fähig“ unterschiedliche Anforderungen sind.
Basis-Worker-Runtime ermöglicht Deployment; Dynamic Workers ermöglicht isolierte Plugin-Ausführung.

Wann sollte ich einen kostenpflichtigen Plan ernsthaft prüfen?

Upgrade prüfen, wenn mindestens eines zutrifft:

Sie müssen Plugins aus teilweise nicht vertrauenswürdigen Quellen ausführen
Compliance verlangt Nachweise zur Plugin-Isolation
Geschäftsschaden durch Plugin-Privilegien-Missbrauch ist inakzeptabel

Wenn das noch nicht zutrifft, stabiler Betrieb im Free-Tier ist eine legitime Strategie.

Minimale Pre-Launch-Checkliste im Free-Tier

Vor Launch bestätigen:

worker_loaders ist entfernt.
D1/R2-Binding-Namen sind konsistent.
Plugin-Liste enthält keine Einträge, die Sandbox zwingend brauchen.
Post-Release-Validierung deckt Content Schreiben/Lesen und Medien-Upload ab.

Diese vier Checks senken das Incident-Risiko wirksamer als voreilige Plan-Upgrades.

Konfigurationsbeispiel Free-Tier

{
  "d1_databases": [{ "binding": "DB", "database_name": "your-db", "database_id": "..." }],
  "r2_buckets": [{ "binding": "MEDIA", "bucket_name": "your-media-bucket" }]
  // Kein worker_loaders im Free-Plan
}