Héberger le serveur Crunu sur Cloudflare Workers et D1

Ce que fait Crunu sur Cloudflare

Crunu tourne dans le cloud sur app.crunu.com : vous n’avez donc rien à déployer pour commencer. Si vous voulez votre propre serveur sans gérer de machine, le serveur Crunu a une version pour Cloudflare Workers qui stocke ses données dans D1.

Sur Workers comme partout ailleurs, le serveur est aveugle : D1 contient des données chiffrées, des clés publiques, des documents signés et des métadonnées, jamais une clé capable de déchiffrer une valeur.

Déployer

Il vous faut Node.js 24, wrangler avec wrangler login effectué, et un fichier .env créé par server-init. Les commandes se lancent depuis le répertoire du serveur Crunu, où se trouvent les scripts de déploiement.

node scripts/server-init.mjs --origin https://vault.company.example
sh deploy/cloudflare/deploy.sh --name vault-company --location weur

Le script vérifie le .env avec le code qu’utilise le serveur au démarrage, construit le Worker, crée la base D1 vault-company-db si elle n’existe pas, et déploie le Worker avec ses secrets en une seule version. Le code et les clés changent au même moment, et si le déploiement échoue, rien ne change sur le Worker. Les migrations de schéma s’exécutent à la première requête.

Pour construire et inspecter ce qui serait déployé sans le déployer, ajoutez --build-only. Le script affiche l’empreinte du build et le nom des secrets qu’il enverrait, puis s’arrête. Le build est reproductible : la même commande sans l’option déploie donc exactement ce que vous avez inspecté.

Rattachez votre propre domaine au Worker dans le tableau de bord Cloudflare et utilisez-le comme PUBLIC_ORIGIN du serveur. Le nettoyage des sessions expirées et l’élagage du journal d’audit tournent sur un déclencheur cron toutes les 5 minutes.

Choisir la bonne offre

Réglages à vérifier après le déploiement

• Compression des réponses de l’API. Le Worker répond à /v2/* sans compression, pour que la taille des réponses ne trahisse rien. Lancez doctor contre votre domaine. S’il signale une compression, ajoutez une Compression Rule qui désactive la compression pour les chemins commençant par /v2/.
• URL de préversion. Chaque version de Worker envoyée peut avoir sa propre adresse workers.dev qui fonctionne avec la même base de données et les mêmes secrets. Le modèle de Crunu désactive les URL de préversion, et le script de déploiement les désactive aussi pour les anciennes versions du Worker. Ne les réactivez pas.
• Pseudo IPv4. Pour les restrictions réseau, laissez le réglage Pseudo IPv4 de la zone désactivé ou sur Add header. En mode Overwrite headers, les clients IPv6 apparaissent sous des adresses de substitution et ne correspondent pas aux règles IPv6.

node scripts/doctor.mjs https://vault.company.example

Cloudflare Tunnel pour votre propre machine

Si vous préférez faire tourner le serveur sur votre propre machine, Cloudflare Tunnel le publie sans port ouvert. Cette configuration fait partie de l’intégration Docker.

Secrets Cloudflare pour vos propres applications

Crunu n’a pas de synchronisation intégrée vers les secrets Cloudflare. Si l’un de vos Workers garde ses valeurs dans Cloudflare, un pipeline peut les y pousser avec la CLI de Cloudflare lancée sous crunu run, au moyen d’un jeton de production lié par OIDC à main et à l’environnement de déploiement de production. Chaque exécution apparaît dans le journal d’audit de Crunu. La page Vercel montre ce schéma avec une commande concrète.

Voir aussi

• Auto-hébergement
• Cloudflare Workers dans la documentation
• Changer de plateforme
• GitHub Actions