FAQ sur les limites du plan Cloudflare Free pour Emdash CMS

Publié le 2026-04-08 par Emdash Cms Everything

Que limite le plan Cloudflare Free dans Emdash CMS ?

Les workflows CMS principaux restent disponibles, mais pas l’exécution sandbox des plugins.
En pratique, la gestion de contenu et le déploiement standard du site fonctionnent, pas l’isolation des plugins dépendant de Dynamic Workers.

Est-ce que worker_loaders doit rester dans la configuration ?

Non. Retirez-le sur le plan Free.
Le laisser en place provoque souvent des échecs de déploiement ou d’exécution car il dépend de capacités payantes.

Puis-je tout de même mettre en production sur le plan Free ?

Oui, avec des limites claires :

• adapté au contenu, à la doc et aux sites marketing
• inadapté si votre flux principal dépend de plugins tiers sandboxés

Si l’exécution sandbox n’est pas critique, le Free suffit souvent pour démarrer.

Comment gérer les plugins prudemment sur le plan Free ?

Politique de plugins de confiance :

• activer des plugins avec propriété vérifiable
• revoir dépendances et permissions avant release
• déplacer la logique d’intégration à risque vers des services backend isolés

Le Free n’est pas « pas de plugins », c’est « pas de runtime isolé pour plugins non fiables ».

Pourquoi le déploiement peut réussir alors que les plugins échouent ?

Parce que « déployable » et « capable de sandbox » sont des exigences différentes.
Le runtime Worker de base permet le déploiement ; Dynamic Workers permet l’exécution sandbox des plugins.

Quand évaluer sérieusement un plan payant ?

Envisagez un upgrade si au moins une condition est vraie :

• vous devez exécuter des plugins provenant de sources partiellement non fiables
• la conformité exige une preuve d’isolation au niveau plugin
• l’impact métier d’un abus de privilèges plugin est inacceptable

Si ce n’est pas encore le cas, opérer stablement sur le Free est une stratégie valide.

Checklist minimale avant lancement (Free)

Vérifiez avant le go-live :

1. worker_loaders est supprimé.
2. Les noms de binding D1/R2 sont cohérents.
3. La liste des plugins ne contient pas d’entrées exigeant la sandbox.
4. La validation post-release couvre écriture/lecture de contenu et upload média.

Ces quatre points réduisent le risque d’incident mieux que des upgrades anticipés.

Exemple de configuration Free

{
  "d1_databases": [{ "binding": "DB", "database_name": "your-db", "database_id": "..." }],
  "r2_buckets": [{ "binding": "MEDIA", "bucket_name": "your-media-bucket" }]
  // Pas de worker_loaders sur le plan Free
}