Faites tourner le serveur là où vous travaillez déjà
Le serveur Crunu est aveugle par conception. Sur app.crunu.com comme sur une infrastructure que vous contrôlez, il stocke des données chiffrées, des clés publiques et des enregistrements signés, et ne détient aucune clé capable de déchiffrer la moindre valeur.
Avant l’installation
- 1Node.js 24 et le code du serveurLes outils d’exploitation server-init, doctor et crunu-server en ont besoin. Le serveur n’est pas en téléchargement public : écrivez à support@crunu.com pour l’obtenir.
- 2Une adresse que vous garderezLes signatures de connexion, les liens de partage, les clés d’accès (passkeys) et les agents sont liés au domaine du serveur : il ne peut donc pas changer par la suite.
- 3Un endroit sûr pour le .envUn gestionnaire de mots de passe convient. Le fichier contient SERVER_KEY, le secret principal du serveur.
Une fois par serveur
Installer
Cinq étapes vous mènent d’une machine ou d’un compte cloud vide à un serveur en marche avec son premier propriétaire.
1Décidez qui exploite le serveur
Le chiffrement a lieu dans le navigateur et dans l’agent
crunu, jamais sur le serveur. Choisir entre app.crunu.com et votre propre serveur revient donc à choisir qui l’exploite et qui voit ses métadonnées. Dans les deux cas, personne côté serveur ne peut lire vos valeurs.- app.crunu.com : Crunu exploite le serveur sur Cloudflare Workers avec une base de données D1, gratuitement pendant l’accès anticipé
- Votre propre serveur : vous l’exploitez, vous payez votre fournisseur de plateforme, et vous seul voyez ses métadonnées
- Les métadonnées, ce sont les noms des organisations, des projets, des environnements et des machines, les adresses e-mail, le journal d’audit, ainsi que la taille et l’heure des versions
Exemple. Kiteline est une entreprise fictive. 2Générez les réglages du serveur
server-initécrit un fichier.envavec une nouvelleSERVER_KEY, unBOOTSTRAP_TOKENà usage unique pour le premier propriétaire et unCRON_SECRET. Seul votre utilisateur peut lire ce fichier.- Enregistrez-en tout de suite une copie dans votre gestionnaire de mots de passe
- Perdre SERVER_KEY déconnecte tout le monde et casse les liens de partage. Les données des environnements, elles, sont conservées
3Choisissez l’une des cinq plateformes
Chaque plateforme fait tourner le même serveur avec le même schéma de base de données, et l’application web y est intégrée. Chaque script de déploiement vérifie le
.envavec le code qu’utilise le serveur au démarrage : un mauvais réglage arrête donc le déploiement avec un message clair.- Docker sur votre propre serveur : Caddy émet les certificats TLS, et Cloudflare Tunnel convient si vous ne voulez aucun port ouvert
- Cloudflare Workers : l’offre Free suffit pour un essai, mais une équipe a besoin de Workers Paid, car Free accorde 10 ms de temps CPU par requête
- Vercel : les préversions ont leur propre base de données et leur propre clé de serveur, et avec le forfait Hobby, le nettoyage tourne au plus une fois par jour
- AWS App Runner seulement dans les comptes AWS qui l’utilisent déjà : AWS l’a fermé aux nouveaux clients, et Crunu n’a pas de script pour Amazon ECS Express Mode
Exemple. Kiteline est une entreprise fictive. 4Déployez avec le script de la plateforme
Une commande par plateforme construit et déploie le serveur. Les secrets parviennent à la plateforme par stdin ou par un fichier que vous seul pouvez lire, jamais par les arguments de commande ni par la sortie. Le serveur applique lui-même les migrations de la base de données au démarrage.
- Le même script installe la première version et chaque mise à jour
- Sur Cloudflare, le code et les secrets partent en une seule version : un déploiement raté ne change donc rien
5Créez le premier propriétaire
Ouvrez l’adresse du serveur et saisissez la clé d’amorçage tirée du
.env. Les clés de votre compte et de l’organisation sont créées dans votre navigateur, et la clé d’amorçage cesse de fonctionner après cet unique usage. Conservez ensuite votre Emergency Kit, créez un code de récupération et activez un second facteur.- Sans l’Emergency Kit et votre mot de passe, un nouvel appareil ne peut pas se connecter
- Toutes les autres personnes rejoignent l’organisation sur invitation
Au quotidien
Exploiter
Une fois le serveur en place, trois habitudes le gardent en bonne santé : une vérification après chaque déploiement, la surveillance et une sauvegarde quotidienne.
6Vérifiez le déploiement avec doctor
doctorvérifie de l’extérieur un serveur en marche : état de santé, TLS et expiration du certificat, en-têtes de sécurité, compression des réponses de l’API, horloge du serveur, version de l’agent, migrations, nettoyage et adresse du client derrière les proxys.- Un résultat global et un code de sortie : l’outil s’intègre donc à cron et à la CI
- --json produit une sortie lisible par une machine
7Surveillez la santé, les métriques et les alertes
GET /v2/healthfonctionne avec des outils de surveillance de disponibilité comme UptimeRobot ou Better Stack.GET /v2/status, avec un jeton d’opérateur, renvoie les métriques en JSON ou au format Prometheus, sans aucune valeur ni adresse e-mail. Les alertes parviennent à votre équipe par un webhook signé ou par e-mail.- Slack, Microsoft Teams et PagerDuty se branchent via leurs webhooks entrants
- Sur Cloud Run et App Runner, le nettoyage ne tourne que s’il y a du trafic : les alertes fondées sur l’état peuvent donc arriver en retard
8Sauvegardez vers le stockage de votre choix
crunu-server exportécrit toute la base de données dans une seule archive. Elle ne contient aucune valeur en clair : vous pouvez donc la confier à n’importe quel fournisseur. Gardez le fichier.envà part, dans votre gestionnaire de mots de passe.- Exportez chaque jour et gardez 30 jours. Le serveur n’a pas de planificateur intégré, et le guide des sauvegardes donne une ligne cron prête à l’emploi pour Docker
- Vérifiez une copie chaque mois, ou mieux, restaurez-la dans une base de données de test
- Une restauration annule tout ce qui suit la copie, et les appareils qui ont vu des données plus récentes refusent l’état plus ancien tant que vous ne les avez pas réinitialisés
Au besoin
Faire évoluer
Le déménagement, le renouvellement de la clé du serveur et les mises à jour passent par les scripts de déploiement et crunu-server que vous avez déjà.
9Changez de plateforme avec une seule archive
Exportez la base de données, vérifiez l’archive, importez-la dans une base vide sur la nouvelle plateforme et déployez-y avec le même
.env, puis basculez le DNS. Chacune des six configurations peut passer à n’importe quelle autre, dans les deux sens.- Gardez la même SERVER_KEY et la même adresse. Seul l’enregistrement DNS change
- Les machines continuent de tourner avec les variables qu’elles ont déjà, le temps de leur bail, jusqu’à 24 heures
- Gardez l’ancienne plateforme une semaine. Revenir en arrière n’est qu’un changement de DNS
Exemple. Kiteline est une entreprise fictive. 10Renouvelez la clé du serveur sans déconnecter personne
Pendant un renouvellement, la clé précédente continue de fonctionner, les jetons sont rehachés avec la nouvelle clé au fil de leur utilisation, et
rotate-keyrechiffre les secrets TOTP et les canaux d’alerte. Les personnes restent connectées et les liens de partage continuent de s’ouvrir. Les données des environnements ne sont jamais chiffrées avec cette clé.- Quatre étapes : new-server-key, deploy, rotate-key, drop-previous-key
- Renouvelez la clé quand le .env a pu être vu, après un déménagement, ou une fois par an
11Mettez à jour sans étape de migration séparée
Une mise à jour passe par le même script de déploiement que la première installation, et le serveur applique les migrations au démarrage. Les migrations ne font qu’ajouter, et celles déjà publiées sont protégées par des sommes de contrôle : vous pouvez donc revenir à un code antérieur sans restaurer la base de données.
- Les versions web sont signées, et le serveur sert la signature pour qu’un site déployé puisse être vérifié avec elle
- Revenir à une version antérieure à la 6.0 n’est pas possible
Questions sur l’auto-hébergement
Ce que demandent les exploitants avant de faire tourner leur propre serveur.
Une autre question ? Écrivez à support@crunu.com.
app.crunu.com est-il le même logiciel que celui que je peux héberger moi-même ?
Oui. app.crunu.com fait tourner le même serveur Crunu, déployé sur Cloudflare Workers avec une base de données D1.
Les personnes qui exploitent app.crunu.com peuvent-elles lire mes secrets ?
Non. Le serveur stocke des données chiffrées et n’a aucune clé pour les déchiffrer. En tant qu’exploitant, Crunu voit en revanche les métadonnées : noms des organisations, des projets, des environnements et des machines, adresses e-mail, journal d’audit, taille et heure de chaque version. Un risque concerne tout coffre-fort accessible par le web : un serveur compromis pourrait servir une application web modifiée qui verrait votre mot de passe et votre Secret Key à la connexion. Les versions signées et une politique de sécurité du contenu stricte réduisent ce risque, et la page des limites explique le reste.
Puis-je passer plus tard d’app.crunu.com à mon propre serveur ?
Pas en une seule étape. L’archive qui fait passer un serveur d’une plateforme à l’autre est tirée de toute la base de données du serveur, et sur app.crunu.com, seul l’exploitant y a accès. À tout moment, vous pouvez exporter chaque environnement que vous pouvez lire sous forme de fichier .env ou télécharger une copie hors ligne, puis ajouter ces fichiers à votre propre serveur. L’historique, les réglages d’accès et le journal d’audit ne suivent pas par ce moyen.
AWS est-il pris en charge ?
En partie. Le script Crunu déploie sur AWS App Runner, mais AWS a fermé App Runner aux nouveaux clients : cela ne fonctionne donc que dans les comptes qui l’utilisent déjà. Crunu n’a pas de script pour Amazon ECS Express Mode, le service qu’AWS recommande à la place. Avec un nouveau compte AWS, choisissez Cloud Run, Vercel ou votre propre serveur.
Qu’arrive-t-il aux machines et à la CI pendant un déménagement ?
Les machines continuent de tourner avec les variables qu’elles ont déjà, le temps de leur bail, jusqu’à 24 heures. Demandez à l’équipe de ne pas modifier les environnements ni inviter de personnes pendant 15 à 30 minutes, le temps de la bascule : ce qui est écrit sur l’ancien serveur après l’export n’atteindra pas le nouveau.
Puis-je faire tourner plusieurs instances du serveur pour la haute disponibilité ?
Avec Postgres, plusieurs instances peuvent partager une même base de données : les écritures dans le journal d’audit sont sérialisées par un verrou de la base. Il n’existe pas de guide pour un cluster de basculement : prévoyez-le comme votre propre configuration.
Les outils d’exploitation ont-ils une interface en anglais ?
Oui. server-init, doctor et crunu-server affichent leurs messages en anglais, ou en russe lorsque CRUNU_LANG ou la locale du système indique le russe.
Comment obtenir le serveur pour l’auto-héberger ?
Le serveur n’est pas proposé en téléchargement public. Écrivez à support@crunu.com en indiquant la plateforme que vous comptez utiliser.
Essayez d’abord Crunu sur le service hébergé
Gratuit pendant l’accès anticipé. Votre mot de passe et votre Secret Key sont créés dans votre navigateur et n’atteignent jamais le serveur.