Puis-je laisser n8n cloud actif en parallèle de l'auto-hébergé pour comparer ?

Oui, c'est même recommandé pendant la phase de tests parallèles. Vos workflows tournent en double : ceux sur n8n cloud restent actifs et continuent de répondre aux webhooks publics, vos copies sur l'auto-hébergé sont en mode 'Inactive' (vous les exécutez manuellement pour tester). Coût : votre abonnement n8n cloud le temps de la migration (1 mois en général).

Que faire si un workflow utilise des nodes communautaires (custom nodes) ?

Sur n8n cloud les custom nodes ne sont pas supportés (sauf plans entreprise). Si vos workflows en utilisent, vous êtes déjà sur l'auto-hébergé probablement, ou vous avez contourné. Sur votre nouvelle instance, installez les nodes via la commande n8n install dans le container, ou via la marketplace de la version 2.x.

Comment migrer l'historique des exécutions (logs des runs passés) ?

Hélas, l'historique des exécutions ne s'exporte pas via l'API n8n cloud (limitation actuelle, peut évoluer). Si vous avez besoin de cet historique pour audit ou analyse, faites des captures d'écran ou exports manuels avant la migration. Sur l'auto-hébergé, l'historique repart à zéro (et grandira au fil des exécutions, avec auto-prune à 7 jours par défaut).

Mes utilisateurs n8n cloud peuvent-ils continuer à se connecter pendant la migration ?

Oui sans problème, n8n cloud reste totalement opérationnel pendant que vous préparez l'auto-hébergé en parallèle. Communiquez à votre équipe la date de bascule (ex: 'le lundi X mai à 9h, on passe sur la nouvelle URL'). Recréez leurs comptes utilisateur sur l'auto-hébergé avec les mêmes emails, ils retrouveront leurs accès.

Y a-t-il une commande n8n CLI pour exporter les credentials chiffrés (pas en clair) ?

Oui mais uniquement sur n8n auto-hébergé : 'docker compose exec n8n n8n export:credentials --all --output=creds.json' exporte les credentials toujours chiffrés avec votre encryption key. Utile pour migrer entre deux instances auto-hébergées qui partagent la même clé. Pas applicable depuis n8n cloud (vous n'avez pas accès à la CLI).

Chapitre 6 : Migration depuis n8n cloud

Le piège fondamental de la migration n8n cloud.

Avant de plonger dans la procédure technique, il faut comprendre une réalité importante : les credentials n8n ne s'exportent jamais en clair. Et c'est volontaire, c'est de la sécurité.

Quand vous exportez un workflow depuis n8n cloud (au format JSON), seules les références aux credentials sont exportées (par leur nom et type), pas leur contenu. Vos clés API, tokens OAuth, mots de passe SMTP, etc. restent chiffrés sur les serveurs n8n cloud avec leur encryption key, et vous ne pouvez pas les sortir en clair.

Conséquence pratique : vous devrez recréer manuellement chaque credential sur votre nouvelle instance auto-hébergée. Pour 20 credentials uniques, comptez 30-45 minutes de saisie. C'est rébarbatif mais pas long.

Étape 1 : audit complet de votre instance n8n cloud.

Avant tout export, faites le ménage et inventorier. Connectez-vous à votre n8n cloud et listez :

Workflows actifs et inactifs : combien en tout, lesquels sont vraiment utilisés ? La migration est une bonne occasion d'archiver ceux qui dorment depuis 6 mois.
Workflows critiques : ceux qui ne doivent absolument pas tomber pendant la bascule. Identifiez leurs déclencheurs (webhook public ? cron interne ? polling externe ?).
Credentials utilisés : Settings → Credentials. Notez nom, type, et le service externe associé.
Webhooks publics : URL au format https://votrecompte.app.n8n.cloud/webhook/.... Lesquels sont configurés en dur dans des services tiers (Stripe, GitHub, formulaires web) ? Vous devrez tout reconfigurer après bascule.
Variables d'environnement : si vous en avez défini dans n8n cloud (UI Settings), elles devront être recréées.
Utilisateurs : liste des emails ayant accès, leur rôle (owner, admin, member). Vous les recréerez sur l'instance auto-hébergée.

Étape 2 : export des workflows en JSON.

Vous avez deux options pour exporter vos workflows :

Option A : export via l'UI (workflow par workflow).

Pour chaque workflow : ouvrir → menu (... en haut droite) → Download. Vous obtenez un fichier JSON par workflow. Lent si vous en avez 50, mais ça marche.

Option B : export via l'API n8n cloud (en lot).

n8n cloud expose une API REST authentifiée par clé personnelle. Plus rapide pour des migrations en masse :

# Generer une cle API : n8n cloud > Settings > API > Create API Key
API_KEY="VOTRE_CLE_API"
N8N_URL="https://votrecompte.app.n8n.cloud"

# Lister tous les workflows
curl -H "X-N8N-API-KEY: $API_KEY" \
  "$N8N_URL/api/v1/workflows" \
  | jq '.data[] | {id, name}'

# Exporter un workflow par ID
curl -H "X-N8N-API-KEY: $API_KEY" \
  "$N8N_URL/api/v1/workflows/WORKFLOW_ID" \
  > workflow_WORKFLOW_ID.json

Avec un peu de scripting bash ou Python, vous pouvez exporter tous vos workflows en un coup. Stockez le dossier workflows-export/ dans Git ou un drive sécurisé : c'est une archive précieuse.

Étape 3 : recréer les credentials sur l'instance auto-hébergée.

Avant d'importer les workflows, créez tous les credentials nécessaires sur votre n8n auto-hébergé. C'est plus rapide de tout faire d'un coup que d'aller-retour entre import et création de credentials.

Pour chaque credential identifié à l'étape 1 :

Sur n8n auto-hébergé : Credentials → New
Sélectionnez le type (Stripe, OpenAI, Google Sheets, etc.)
Donnez exactement le même nom que sur n8n cloud (case-sensitive). C'est ce qui permettra aux workflows importés de retrouver leurs credentials sans modification.
Collez les valeurs (clés API, tokens, etc.)
Test de connexion (n8n vérifie en temps réel)
Save

Étape 4 : importer les workflows.

Sur votre instance auto-hébergée, importez les JSON. Deux options à nouveau :

Option A : import UI (recommandé pour <50 workflows).

Pour chaque fichier JSON : workflow vide → menu → Import from file. Le workflow apparaît avec ses credentials résolus si vous les avez bien recréés avec le même nom.

Option B : import via CLI n8n.

# Copier les JSON sur le serveur
scp -r workflows-export/ deploy@VOTRE_IP_VPS:/tmp/

# Importer en lot via la CLI n8n (depuis le container)
docker compose exec n8n n8n import:workflow --separate --input=/tmp/workflows-export

Vérifiez immédiatement après import :

Tous les workflows sont listés
Les credentials affichent les bons noms (pas de "missing credential")
Les workflows sont en statut "Inactive" par défaut (n'activez rien encore)

Étape 5 : tester en parallèle, sans bascule.

Avant la bascule définitive, testez en parallèle. n8n cloud reste actif et continue de servir vos webhooks publics. Sur n8n auto-hébergé, vous activez les workflows un par un et vous les testez manuellement.

Pour chaque workflow critique :

Activez-le sur n8n auto-hébergé
Lancez une exécution manuelle (bouton "Execute Workflow")
Vérifiez que le résultat correspond à ce qu'il faisait sur n8n cloud
Si OK, désactivez-le (on bascule en une seule fois plus tard)
Si KO : debug, corriger, retester

Ce sas de test évite les régressions silencieuses. Comptez 1-2 minutes par workflow.

Étape 6 : bascule des webhooks publics.

C'est l'étape la plus délicate. Vos webhooks publics sont au format https://votrecompte.app.n8n.cloud/webhook/xxx. Sur n8n auto-hébergé, ils deviennent https://n8n.votreboite.fr/webhook/xxx. Le path après /webhook/ est identique (il dépend du node Webhook dans le workflow), seul le domaine change.

Stratégie recommandée : migration en deux phases.

Phase 1 : redirections HTTP côté n8n cloud (quelques jours).

Tristesse : n8n cloud ne permet pas de redirection HTTP native. Il faut donc :

Soit modifier les services tiers (Stripe, GitHub, etc.) un par un pour pointer vers la nouvelle URL
Soit mettre en place un reverse proxy intermédiaire (un autre VPS) qui redirige votrecompte.app.n8n.cloud/webhook/* vers n8n.votreboite.fr/webhook/*, mais cela suppose que vous avez le contrôle DNS de votrecompte.app.n8n.cloud ce qui est faux pour un sous-domaine .app.n8n.cloud

En pratique, la solution est la mise à jour côté services tiers. Faites la liste exhaustive de tous les webhooks et mettez-les à jour service par service.

Phase 2 : activation des workflows sur n8n auto-hébergé.

Quand tous les services tiers pointent vers la nouvelle URL :

Désactivez tous les workflows sur n8n cloud (mais ne supprimez rien)
Activez tous les workflows sur n8n auto-hébergé
Surveillez les exécutions pendant 24h pour repérer les déclenchements manqués

Étape 7 : surveillance et fermeture du compte.

Pendant 1 à 2 semaines, gardez votre abonnement n8n cloud actif. Surveillez régulièrement le tableau de bord exécutions pour vérifier qu'il ne reste pas de workflows déclenchés (ce qui voudrait dire qu'un service tiers utilise encore l'ancienne URL).

Quand 7 jours se sont écoulés sans aucune exécution sur n8n cloud, vous pouvez fermer l'abonnement. Avant de fermer définitivement :

Téléchargez une dernière fois tous vos workflows en JSON (archive de sauvegarde)
Téléchargez l'historique des exécutions si possible (limité dans n8n cloud)
Notez l'URL de votre compte au cas où vous voudriez réactiver dans 6 mois

Procédure de fermeture : Settings → Subscription → Cancel. Selon votre plan, le service reste actif jusqu'à la fin de la période payée.

Estimation temporelle réaliste.

Pour donner un cadre temporel à votre projet :

Étape	10 workflows	50 workflows
Audit + inventaire credentials	30 min	1h30
Export JSON	15 min	45 min
Recréation credentials	45 min	2h
Import workflows	15 min	1h
Tests parallèles	45 min	3h
Bascule webhooks tiers	1h	3-4h
Total	~3h30	~12h

Une PME avec 20 workflows peut migrer en une journée de travail tranquille. Au-delà, étalez sur 2-3 jours pour ne pas vous épuiser.

Récapitulatif migration.

✅ Audit complet réalisé (workflows, credentials, webhooks, utilisateurs)
✅ Export JSON de tous les workflows réussi
✅ Credentials recréés sur l'instance auto-hébergée (mêmes noms)
✅ Workflows importés et statut "Inactive"
✅ Tests parallèles validés workflow par workflow
✅ Webhooks tiers mis à jour vers nouvelle URL
✅ Activation finale et désactivation côté n8n cloud
✅ 7 jours de surveillance sans incident
✅ Compte n8n cloud fermé après archive complète

Bravo, vous êtes 100% auto-hébergé. Le chapitre 7 vous montre comment garder ce système en bonne santé : monitoring, mises à jour, et que faire quand vos besoins grandissent (queue mode).

Migrer depuis n8n cloud sans perdre un workflow.