Exécuter un serveur n8n privé que votre équipe sait vraiment restaurer

n8n n’est pas seulement un outil visuel d’automatisation. Il stocke les définitions de workflow, les identifiants chiffrés avec la clé de l’instance, les données d’exécution et la configuration qui indique où les retours d’appel doivent arriver. Une capture de l’éditeur n’est pas une sauvegarde. Une reprise réussie signifie qu’un nouveau serveur démarre avec la même clé de chiffrement, charge un workflow choisi et exécute un test inoffensif sans reconnecter chaque service.

Ce guide utilise l’application n8n en un clic de DigitalOcean sur un Droplet et un compartiment Spaces privé pour les sauvegardes chiffrées. Cette installation n’a pas de basculement automatique. N’ajoutez pas de dossiers clients, de clés API de production ou d’actions financières à un workflow avant d’avoir testé sa gestion des erreurs habituelles et cette procédure de reprise.

L’application Marketplace déploie un Droplet avec la version stable actuelle de n8n et demande de faire pointer un enregistrement DNS A vers ce serveur avant de terminer la configuration. Utilisez une clé SSH pour le compte d’administration. N’activez pas un mot de passe SSH simplement pour rendre la première connexion plus facile.

Créez un pare-feu cloud avant d’inviter une autre personne. Autorisez TCP 80 et 443 pour le service web. Autorisez TCP 22 seulement depuis la sortie de votre VPN ou une adresse IP d’administration fixe. Activez la supervision et les sauvegardes du Droplet, mais considérez-les comme une couche distincte. La sauvegarde de ce guide protège les données et la configuration n8n sous une forme transportable.

Terminez la configuration initiale sur votre domaine HTTPS, pas en gardant l’adresse IP du serveur dans des favoris. Dans le dossier de déploiement, examinez les fichiers Compose et le fichier d’environnement générés avant de les modifier. Définissez l’hôte public, le protocole et l’URL de webhook sur l’adresse HTTPS définitive avec les noms de variables documentés par la version n8n installée. Redémarrez la pile Compose seulement après avoir enregistré une copie protégée de la configuration actuelle.

Dans la disposition Docker et Caddy standard, le volume de données n8n contient la base SQLite et son matériel de chiffrement. L’archive de ce volume est le registre de reprise des identifiants. Si vous définissez N8N_ENCRYPTION_KEY hors de ce volume, conservez aussi l’archive de configuration protégée. Renouveler une clé est une tâche de maintenance volontaire, pas une étape de dépannage. Une sauvegarde sans la clé correspondante peut afficher des identifiants qu’elle ne peut pas utiliser.

Créez un compartiment Spaces privé, par exemple n8n-recovery-your-team, dans une région choisie délibérément. N’activez ni listing public ni CDN. Activez le versionnage, puis créez une règle de cycle de vie qui conserve les archives principales pendant une durée approuvée par l’équipe. Quatre-vingt-dix jours sont un bon premier choix sans objectif de reprise défini. Créez ensuite une clé Spaces séparée et limitée à ce compartiment. Les clés limitées DigitalOcean proposent Read ou Read/Write/Delete. La tâche d’envoi exige sa propre clé Read/Write/Delete, car il n’existe pas de clé plus limitée en écriture seule. Conservez cette clé dans un fichier lisible par root sur le Droplet, avec le mode 600. Gardez aussi la clé publique du destinataire age ici. Conservez la clé privée correspondante hors du Droplet, par exemple dans un gestionnaire de mots de passe d’équipe avec un accès de reprise.

La sauvegarde reste illisible dans Spaces sans l’identité age hors ligne. Cela limite les dégâts si une clé Spaces fuit, mais cela signifie aussi qu’il faut vérifier que la personne de reprise peut utiliser cette identité avant de considérer la tâche comme fiable.

La disposition Compose de l’application en un clic peut changer avec le temps. Ne copiez pas le nom d’un volume depuis cet article. Utilisez docker volume ls et la configuration Compose relevée plus haut pour identifier le volume qui contient les données n8n. Ce guide couvre la disposition Marketplace Docker et Caddy avec des données n8n persistantes dans un volume. Si vous la remplacez volontairement par PostgreSQL, utilisez la procédure documentée d’export et de restauration du fournisseur de base, et testez-la comme un plan de reprise séparé.

Le script ci-dessous arrête brièvement la pile Compose, archive le volume n8n nommé et la configuration de déploiement, chiffre les deux avec votre destinataire public age, puis envoie les fichiers chiffrés. Définissez VOLUME_NAME seulement après avoir inspecté votre serveur. Le script refuse volontairement de le deviner. Il construit un manifeste de configuration à partir des fichiers réellement présents, inclut la configuration Caddy lorsqu’elle existe et échoue s’il ne trouve pas de fichier Compose. Exécutez-le une fois à la main avant de le planifier.

Une sauvegarde qui échoue sans bruit est pire que l’absence de sauvegarde parce qu’elle donne une fausse confiance. Commencez avec une exécution quotidienne et un journal, puis reliez les échecs au système d’alerte que votre équipe regarde déjà. Choisissez la fréquence selon l’état d’automatisation que vous pouvez perdre. Pour un workflow qui crée des dossiers clients toutes les quelques minutes, une exécution quotidienne n’est probablement pas suffisante.

Toutes les quelques semaines, listez le préfixe du compartiment et comparez les deux archives les plus récentes avec le planning. Les archives du volume et de la configuration doivent avoir le même horodatage. Examinez une paire manquante avant la prochaine modification habituelle du serveur.

Un test de restauration ne doit ni écraser le Droplet de production ni contacter les systèmes de production. Créez un Droplet Linux temporaire avec un pare-feu cloud séparé. Utilisez un sous-domaine de test dédié, pas le nom d’hôte de production. Pendant l’émission du certificat, autorisez TCP 80 et 443 ainsi que le trafic sortant nécessaire à Caddy, mais démarrez seulement le service de proxy inverse. Limitez ensuite HTTPS à l’adresse IP de l’administrateur de reprise et bloquez le trafic sortant avant de démarrer n8n. Cela évite les e-mails, paiements, écritures CRM et appels webhook en double pendant le démarrage de l’instance récupérée.

Installez awscli, age, Docker Engine et le module Docker Compose sur le Droplet de test. Utilisez une clé Read limitée au compartiment et distincte de la clé d’envoi de production. Installez la même version d’image n8n, créez un volume de données nommé et vide, puis récupérez une archive de volume et une archive de configuration ayant le même horodatage. Utilisez l’identité privée age détenue par la personne de reprise seulement sur la machine de test. Ne la copiez pas sur le serveur de production. Extrayez l’archive de configuration dans un nouveau dossier Compose et restaurez l’archive chiffrée du volume dans le nouveau volume vide. Vérifiez l’étiquette d’image, l’URL publique et le traitement de la clé de chiffrement avant de démarrer n8n. Connectez-vous via le pare-feu limité à l’administrateur, désactivez tous les workflows, puis lancez un test manuel de nœud Set. Détruisez le Droplet de test ou retirez les identifiants récupérés quand vous avez terminé.

Dépassez le Droplet unique lorsque vous avez besoin d’un objectif de délai de reprise documenté, de plusieurs opérateurs qui modifient des workflows, d’un grand volume d’exécutions ou d’un workflow dont l’arrêt peut créer un problème matériel pour un client ou une opération financière. À ce stade, utilisez une base de données gérée lorsque c’est adapté, testez les sauvegardes de base séparément, gérez les secrets hors du Droplet et notez qui peut approuver une reprise.

N’utilisez pas un workflow n8n comme unique moyen de sauvegarder n8n. Le travail de sauvegarde doit rester hors de l’application qu’il protège. Cette séparation simple permet de récupérer le service lorsque c’est le service de workflow qui a échoué.