Migrer de n8n Cloud vers une instance self-hosted : le guide pas à pas

Démarrer sur n8n Cloud puis migrer en self-hosted quand le volume ou les exigences de conformité le justifient : c'est la trajectoire la plus courante, celle que nous décrivions déjà dans notre comparatif self-hosted vs Cloud. La bonne nouvelle, c'est que les workflows n8n sont portables par conception — un JSON exporté du Cloud s'importe tel quel sur votre serveur. La moins bonne, c'est que tout le reste ne suit pas automatiquement : credentials, connexions OAuth, URLs de webhooks. Ce guide déroule la migration étape par étape, dans le bon ordre, pour basculer sans casser vos automatisations en production.

Pourquoi migrer — et pourquoi parfois rester

Trois raisons reviennent systématiquement chez ceux qui quittent le Cloud :

• Le coût à volume élevé. n8n Cloud facture par paliers d'exécutions mensuelles (voir notre guide des tarifs n8n Cloud). Tant que le volume reste modeste, l'abonnement se justifie ; quand des workflows IA tournent des centaines de fois par jour, le self-hosted ramène le coût marginal d'une exécution à quasi zéro — notre analyse du coût réel d'un n8n self-hosted chiffre le point de bascule.
• La maîtrise des données. Sur votre serveur, les payloads de vos workflows (emails clients, données CRM, documents) ne transitent plus par un sous-traitant. Pour une activité soumise à des exigences RGPD fortes, c'est souvent l'argument décisif.
• La liberté technique. Variables d'environnement avancées, community nodes sans restriction, réglages fins du stockage binaire ou du mode queue : le self-hosted donne accès à tout ce que le Cloud verrouille par design.

Et une bonne raison de rester sur le Cloud : la maintenance. Mises à jour, sauvegardes, disponibilité, sécurité — tout cela devient votre responsabilité en self-hosted. Si personne dans l'équipe n'a envie d'administrer un serveur, l'abonnement Cloud achète une tranquillité qui vaut son prix. La migration décrite ici s'adresse à ceux qui ont fait ce calcul et choisi la maîtrise.

Étape 1 — Préparer l'instance cible avant de toucher au Cloud

La règle d'or : la cible doit être opérationnelle avant d'exporter quoi que ce soit. Une migration où l'on installe le serveur en catastrophe pendant que les workflows sont déjà coupés côté Cloud est le meilleur moyen de perdre une journée. Ce n'est pas qu'une intuition : la revue systématique de Jamshidi, Ahmad et Pahl sur les migrations cloud (Cloud Migration Research: A Systematic Review, IEEE Transactions on Cloud Computing, 2013 — voir sur Google Scholar) montre que l'essentiel des risques d'une migration se concentre dans la planification et la phase de transition, quand les deux environnements coexistent. Autrement dit : préparez, puis basculez progressivement — jamais l'inverse.

Concrètement, avant la bascule :

1. Montez l'instance avec Docker Compose en suivant notre guide d'installation n8n avec Docker : PostgreSQL plutôt que SQLite, volumes persistants, N8N_ENCRYPTION_KEY fixée explicitement et sauvegardée en lieu sûr.
2. Configurez HTTPS et le nom de domaine dès le premier jour, avec Traefik ou Caddy. Les connexions OAuth et les webhooks exigent une URL publique en HTTPS — sans elle, impossible de recréer les credentials Google ou Slack.
3. Vérifiez que l'instance vit : créez un workflow de test avec un webhook, appelez-le depuis l'extérieur, confirmez que l'exécution apparaît dans l'historique.

Tant que ces trois points ne sont pas verts, ne touchez à rien côté Cloud.

Étape 2 — Exporter les workflows depuis n8n Cloud

Deux méthodes, selon le volume :

Export manuel depuis l'interface. Ouvrez chaque workflow, menu ⋯ → Download : vous obtenez un fichier JSON complet (nodes, connexions, réglages). Parfait jusqu'à une dizaine de workflows.

Export en masse via l'API REST. n8n expose une API publique : créez une clé API dans les réglages de votre compte Cloud, puis interrogez l'endpoint des workflows :

curl -H "X-N8N-API-KEY: votre-cle" \
  "https://votre-compte.app.n8n.cloud/api/v1/workflows"

Un petit script suffit à boucler sur les résultats et écrire un fichier JSON par workflow. Vérifiez la pagination dans la documentation de l'API pour ne rien oublier — les détails exacts (paramètres, limites) peuvent varier selon les versions.

Deux réflexes au passage : exportez tous les workflows, y compris les inactifs et les brouillons (on regrette toujours celui qu'on a laissé derrière), et versionnez immédiatement ces JSON dans un dépôt Git — c'est l'occasion idéale d'adopter la discipline décrite dans notre guide sauvegarder et versionner ses workflows avec Git.

Étape 3 — Le point critique : les credentials ne migrent pas

C'est le piège de la migration, et autant le dire franchement : vos credentials ne suivront pas. n8n chiffre chaque credential avec la clé de chiffrement de l'instance qui l'a créé. Entre deux instances self-hosted, on peut migrer la base et la N8N_ENCRYPTION_KEY ensemble pour conserver les credentials. Mais depuis n8n Cloud, vous n'avez pas accès à cette clé : la recréation manuelle sur la cible est le seul chemin.

En pratique :

1. Dressez la liste de tous les credentials utilisés (l'écran Credentials du Cloud la donne d'un coup d'œil).
2. Rassemblez les secrets d'origine : clés API depuis les consoles des fournisseurs (OpenAI, Stripe, Brevo…), identifiants SMTP, tokens. Si une clé est introuvable, régénérez-la chez le fournisseur — c'est aussi une bonne occasion de faire tourner les secrets anciens.
3. Recréez chaque credential sur l'instance cible, avec exactement le même nom que sur le Cloud : à l'import du JSON, n8n rattache les nodes aux credentials par nom, et un nommage identique vous épargne de rouvrir chaque node un par un.

Étape 4 — Refaire les connexions OAuth

Les credentials OAuth (Google, Slack, Microsoft, HubSpot…) demandent une étape de plus : l'URL de callback change. Elle contenait le domaine app.n8n.cloud ; elle pointe désormais vers votre domaine. Pour chaque connexion OAuth :

1. Ouvrez la console du fournisseur (Google Cloud Console, portail d'app Slack…) et ajoutez la nouvelle URL de redirection que n8n affiche dans l'écran de création du credential.
2. Créez le credential sur la cible et lancez le flux d'autorisation (Connect my account).
3. Testez avec un node simple (lister les fichiers Drive, poster dans un canal de test) avant de considérer la connexion valide.

Si vous utilisiez les credentials OAuth « pré-configurés » du Cloud (où n8n fournit son propre client OAuth), il faudra créer votre propre application OAuth chez le fournisseur — comptez quelques minutes de plus par service.

Étape 5 — Importer les workflows et mettre à jour les webhooks

L'import est la partie facile : Import from file dans l'UI, ou l'endpoint POST /api/v1/workflows de l'API de votre instance. Importez tout en laissant les workflows inactifs pour l'instant.

Vient ensuite le deuxième piège de la migration : toutes les URLs de webhooks changent, puisque le domaine change. Chaque service tiers qui appelait https://votre-compte.app.n8n.cloud/webhook/... doit désormais appeler https://votre-domaine.fr/webhook/.... Passez en revue :

• les webhooks Stripe, Shopify, WooCommerce, GitHub… déclarés dans les dashboards de ces services ;
• les formulaires (Tally, Typeform, formulaires de site) qui postent vers un webhook n8n ;
• les intégrations maison et les crons externes qui appellent vos endpoints ;
• les URLs de webhook codées en dur… dans d'autres workflows n8n.

Un tableau à trois colonnes — service, ancienne URL, nouvelle URL — évite d'en oublier. C'est typiquement le genre d'inventaire qu'on regrette de ne pas avoir tenu dès le départ.

Étape 6 — Double-run et bascule progressive

Ne coupez pas le Cloud d'un coup. La phase de transition — les deux environnements qui coexistent — est celle que la littérature sur les migrations identifie comme la plus risquée ; c'est aussi celle qu'on peut le mieux dérisquer :

1. Classez vos workflows du moins critique au plus critique.
2. Basculez-les un par un : activation sur la cible, mise à jour du webhook chez le service tiers (pour les workflows déclenchés par webhook, la bascule de l'URL est naturellement atomique : un seul environnement reçoit les appels), puis désactivation côté Cloud. Pour les workflows planifiés, désactivez côté Cloud avant d'activer côté cible, sous peine de doubles envois d'emails ou de doubles écritures.
3. Observez chaque workflow quelques jours en conditions réelles avant de passer au suivant.
4. Gardez l'abonnement Cloud actif une à deux semaines après la dernière bascule, comme filet de sécurité, avant de résilier.

Checklist finale avant de considérer la migration terminée

• Tous les workflows importés, testés et actifs sur la cible ; plus aucun actif côté Cloud
• Tous les credentials recréés, connexions OAuth revalidées service par service
• Toutes les URLs de webhooks mises à jour chez les tiers (et vérifiées par un appel réel)
• N8N_ENCRYPTION_KEY sauvegardée hors du serveur
• Sauvegardes PostgreSQL automatisées et restauration testée — une sauvegarde jamais restaurée n'est pas une sauvegarde
• Supervision en place : conteneur, disque, exécutions en échec
• Procédure de mise à jour définie (lire le changelog, sauvegarder, mettre à jour)
• Export Cloud archivé dans Git comme photographie de l'état au jour J

Et vos workflows dans tout ça ?

C'est la vertu cachée de cette portabilité : tout ce qui s'exprime en JSON n8n fonctionne des deux côtés, et le restera. Les packs FlowKit sont construits sur ce principe — le Pack Inbox IA (79 €), le Pack Assistant RAG (119 €) et le Pack Conformité & Audit (149 €) s'importent en JSON sur n'importe quelle instance, Cloud ou self-hosted. Que vous migriez aujourd'hui ou dans un an, vos workflows — achetés ou construits — vous suivent. C'est exactement ce qu'on attend d'un outil d'automatisation : que le choix d'hébergement reste réversible.