Guide de production EmDash CMS sur le plan gratuit Cloudflare

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

Résumé exécutif

Vous pouvez faire tourner EmDash en production sur le plan gratuit Cloudflare pour les flux CMS principaux.
Ce que vous devez accepter : l’exécution sandboxée des plugins n’est pas disponible ; il faut donc retirer worker_loaders de la configuration.

Ce guide privilégie d’abord la stabilité, pas la surface fonctionnelle maximale.

Limites des capacités sur le plan gratuit

Disponible

• Site EmDash principal et flux d’administration
• Données de contenu sur D1
• Stockage média sur R2 (dans les limites d’usage gratuit)
• Déploiement et routage Workers

Non disponible

• Workers dynamiques pour les plugins en bac à sable
• exécution runtime de style marketplace pour du code tiers non fiable

Si votre lancement dépend de l’exécution sandboxée de plugins tiers, le plan gratuit ne suffit pas.

Liste de contrôle avant déploiement

Validez tous les points avant d’exécuter les commandes de déploiement :

• Wrangler est authentifié (wrangler login déjà effectué)
• le projet compile en local sans hypothèses réservées au cloud
• wrangler.jsonc a des liaisons D1 et R2 alignées avec la config runtime
• l’entrée worker_loaders est retirée pour le plan gratuit
• le gestionnaire de paquets est cohérent (npm ou pnpm, pas de mélange)

Ordre de provisionnement des ressources

Provisionnez dans cet ordre exact pour limiter les allers-retours de liaison :

1. Créer la base D1
2. Créer ou activer R2 puis créer le bucket
3. Mettre à jour wrangler.jsonc avec les noms et identifiants exacts
4. Construire et déployer le Worker

Raison : l’ID D1 et les noms de bucket deviennent la source de vérité pour les liaisons d’environnement.

# Provisionner D1 en premier
npx wrangler d1 create your-db-name

# Puis provisionner le bucket R2
npx wrangler r2 bucket create your-media-bucket

Forme minimale de wrangler.jsonc pour le plan gratuit

Le squelette suivant est volontairement minimal :

{
  "$schema": "node_modules/wrangler/config-schema.json",
  "name": "your-site-name",
  "main": "./src/worker.ts",
  "compatibility_date": "2026-04-08",
  "compatibility_flags": ["nodejs_compat"],
  "d1_databases": [
    {
      "binding": "DB",
      "database_name": "your-db-name",
      "database_id": "replace-with-d1-id"
    }
  ],
  "r2_buckets": [
    {
      "binding": "MEDIA",
      "bucket_name": "your-media-bucket"
    }
  ]
}

Pas de section worker_loaders sur le plan gratuit.

Flux de build et déploiement

Exécutez les commandes depuis la racine du projet EmDash :

# choisir un gestionnaire de paquets et s’y tenir
npm run build
npm run deploy

Si le projet est basé sur pnpm :

pnpm build
pnpm deploy

Évitez de mélanger npm et pnpm dans la même session de déploiement sauf si les fichiers de verrouillage sont volontairement synchronisés.

Liste de contrôle après déploiement

Validez dans cet ordre :

1. L’URL front se résout et renvoie le contenu attendu
2. L’URL d’admin (/_emdash/admin) est joignable
3. La première configuration admin se termine correctement
4. Créer et publier un élément de test
5. Téléverser un fichier média et confirmer la récupération

Un déploiement n’est pas terminé tant que les chemins d’écriture des données ne sont pas vérifiés, pas seulement l’accessibilité des routes.

Modes d’échec fréquents et correctifs courts

Échec : déploiement réussi, admin ne s’initialise pas

Cause probable : incohérence des liaisons entre l’intégration runtime et wrangler.jsonc.

Correctif :

1. Vérifier que les noms de liaison (DB, MEDIA) sont identiques partout
2. Redéployer après correction de la config
3. Réessayer l’initialisation admin

Échec : commande R2 bloquée par une invite de compte

Cause probable : R2 pas encore activé dans le tableau de bord.

Correctif :

1. Activer R2 dans le tableau de bord Cloudflare
2. Accepter les conditions de facturation (l’usage gratuit s’applique toujours)
3. Relancer la commande de création de bucket

Échec : erreur runtime liée aux plugins sur le plan gratuit

Cause probable : configuration résiduelle du bac à sable.

Correctif :

1. Retirer worker_loaders
2. Désactiver la configuration plugin spécifique au bac à sable
3. Redéployer et retester

Stratégie de retour arrière

Adoptez une politique de rollback prudente :

• conserver le dernier déploiement connu bon étiqueté par commit
• en cas de régression en production, redéployer le commit étiqueté précédent
• reporter les changements de schéma ou de plugins jusqu’à stabilisation du trafic

En exploitation, un rollback rapide bat un hotfix profond pendant un incident.

Quand passer du gratuit au payant

Ne montez de niveau que si l’un de ces cas est vrai :

• vous avez besoin de l’exécution sandboxée de plugins non fiables
• votre trafic ou stockage dépasse régulièrement les limites gratuites
• la gouvernance exige une isolation runtime des plugins plus forte

Ne montez pas de niveau à cause d’un libellé ambigu dans l’interface de facturation. Ne montez que pour des besoins de capacité concrets.