DEPLOYMENT

Ce document décrit le déploiement de chateauderavenel.fr vers Cloudflare Workers depuis GitLab, sans utiliser les runners partagés GitLab. Le chemin de production attendu est simple : un push sur main, un runner local tagué local, puis un wrangler deploy piloté par wrangler.jsonc.

Façade du Château de Ravenel au coucher du soleil, image de référence du site publié
Le site publié du Château de Ravenel doit rester stable, traçable et contrôlé après chaque mise en production.

Rôle de GitLab

GitLab sert d'historique, de revue et de stockage du code. Il ne doit pas être le lieu d'exécution du build si le projet contient des secrets de déploiement ou dépend d'un environnement local contrôlé.

Le build ne doit donc pas partir sur les runners partagés GitLab. Le job de production doit rester contraint au runner local avec le tag local, afin de limiter l'exposition des variables Cloudflare et de garder une chaîne de déploiement reproductible.

Runner attendu

Le pipeline cible uniquement un runner local avec le tag local.

Prérequis côté GitLab :

  • un GitLab Runner local actif ;
  • le tag local associé au runner ;
  • les variables CLOUDFLARE_API_TOKEN et CLOUDFLARE_ACCOUNT_ID disponibles pour le projet ;
  • les routes Cloudflare chateauderavenel.fr/* et www.chateauderavenel.fr/* associées au Worker ravenel ;
  • Cloudflare Email Sending actif pour le compte ou le domaine, afin que le binding CONTACT_EMAIL puisse envoyer le formulaire à contact@chateauderavenel.fr ;
  • les MX OVH du domaine conservés : mx1.mail.ovh.net, mx2.mail.ovh.net, mx3.mail.ovh.net ;
  • à défaut de Cloudflare Email Sending, le secret RESEND_API_KEY ajouté au Worker pour activer l'envoi via Resend.

Ne pas activer Cloudflare Email Routing si cette option remplace les MX OVH du domaine.

npx --yes wrangler@4.93.1 email sending settings chateauderavenel.fr
npx --yes wrangler@4.93.1 secret put RESEND_API_KEY

Fraîcheur 2026 : pourquoi verrouiller le déploiement

Un déploiement Cloudflare Workers doit être traité comme une opération de production, même pour un site vitrine. La raison est mesurable : dans son rapport 2025 Q4 DDoS threat report, publié en 2026, Cloudflare indique avoir mitigé 47,1 millions d'attaques DDoS en 2025, soit une moyenne de 5 376 attaques par heure. Le même rapport précise que les attaques DDoS ont augmenté de 236 % entre 2023 et 2025.

Pour ce projet, la conséquence pratique est claire : le déploiement doit être déterministe, limité à main, exécuté sur un runner connu et vérifié après publication. Les secrets Cloudflare ne doivent pas être exposés dans les logs, dans le dépôt ou dans des runners partagés.

Modèle de sécurité du pipeline

Le pipeline de production doit réduire la surface d'exposition des secrets et rendre chaque publication explicable. Le runner local tagué local est le point de contrôle : il limite l'exécution à une machine connue, avec des permissions GitLab et Cloudflare explicitement gérées.

Les contrôles minimaux sont les suivants :

  • limiter le job deploy_cloudflare à la branche main ;
  • protéger les variables CLOUDFLARE_API_TOKEN, CLOUDFLARE_ACCOUNT_ID et RESEND_API_KEY ;
  • vérifier que le token Cloudflare ne donne que les permissions nécessaires au déploiement du Worker et à la lecture des ressources utiles ;
  • éviter toute commande qui affiche l'environnement complet dans les logs CI ;
  • conserver wrangler.jsonc comme source de vérité pour le nom du Worker, les routes et les bindings.

Flux

  1. Push sur main vers GitLab.
  2. Le runner local prend le job deploy_cloudflare.
  3. Le site est envoyé à Cloudflare avec wrangler deploy, en utilisant wrangler.jsonc.
  4. Le domaine principal et le domaine www sont testés après publication.
  5. Le formulaire de contact est testé si le changement touche le Worker, les bindings ou les variables d'environnement.

Commande équivalente en local :

npx --yes wrangler@4.93.1 deploy

Checklist post-déploiement

La validation post-déploiement doit confirmer que le Worker publie la bonne version et que les intégrations critiques répondent. Elle se fait juste après le job GitLab, avant de considérer le déploiement terminé.

Points à vérifier :

  • https://chateauderavenel.fr/ répond en HTTPS avec le contenu attendu ;
  • https://www.chateauderavenel.fr/ répond et ne crée pas de boucle de redirection ;
  • les routes Cloudflare pointent toujours vers le Worker ravenel ;
  • le formulaire de contact renvoie une réponse applicative normale ;
  • aucun secret, notamment CLOUDFLARE_API_TOKEN ou RESEND_API_KEY, n'apparaît dans les logs GitLab ;
  • le job GitLab a bien été exécuté par un runner portant le tag local.
curl -I https://chateauderavenel.fr/
curl -I https://www.chateauderavenel.fr/
npx --yes wrangler@4.93.1 deployments list

FAQ

Peut-on utiliser un runner partagé GitLab pour gagner du temps ?

Non. Pour ce projet, le runner partagé est exclu : le déploiement manipule des variables Cloudflare et publie directement en production. Le runner local tagué local reste le seul chemin attendu.

Faut-il activer Cloudflare Email Routing pour le formulaire ?

Non si les MX OVH doivent rester en place. Cloudflare Email Sending peut être utilisé pour envoyer le formulaire via le binding CONTACT_EMAIL, mais Cloudflare Email Routing ne doit pas remplacer les MX OVH du domaine.

Que faire si Cloudflare Email Sending n'est pas disponible ?

Ajouter le secret RESEND_API_KEY au Worker et vérifier que le code utilise le fallback Resend. La commande de référence est npx --yes wrangler@4.93.1 secret put RESEND_API_KEY.

Que vérifier après un changement de wrangler.jsonc ?

Il faut relire les routes, les bindings, les secrets attendus et le nom du Worker avant de déployer. Après publication, tester les deux domaines et le formulaire de contact, car ce sont les surfaces les plus sensibles pour ce projet.

Comment savoir si le bon runner a exécuté le déploiement ?

Dans GitLab, ouvrir le job deploy_cloudflare et vérifier que le runner affiche le tag local. Si le job part sur un autre runner, arrêter le pipeline et corriger les tags avant tout nouveau déploiement.

Faut-il redéployer après une rotation du token Cloudflare ?

Oui si le token précédent était utilisé par le pipeline. Mettre à jour la variable GitLab protégée, lancer un déploiement contrôlé sur main, puis vérifier que wrangler deploy et les routes de production fonctionnent encore.

À retenir

Le déploiement de production du Château de Ravenel doit rester explicite : branche main, runner local, configuration Cloudflare versionnée, secrets protégés et contrôles HTTP après publication.

Contacter le Château de Ravenel