Self-Hosted vers Cloud : quand le changement est-il pertinent chez n8n

Le passage d'une instance n8n self-hosted au n8n Cloud vaut surtout la peine lorsque l'effort consacre aux serveurs, mises a jour et sauvegardes depasse le benefice d'un environnement entierement controle. Cependant, tout ne suit pas automatiquement : selon la documentation n8n, les community nodes non verifies et les nodes construits soi-meme ne fonctionnent qu'en self-hosted, les executions sont plafonnees numeriquement selon le plan Cloud, et les identifiants doivent etre recrees manuellement apres le demenagement, car les fichiers de workflow exportes ne contiennent que les noms et les ID des credentials, pas leurs valeurs. Quiconque connait ces points a l'avance evite de mauvaises surprises apres la migration. Etat : juillet 2026.

Quand le passage au Cloud vaut la peine

En self-hosted, selon n8n lui-meme, vous assumez l'entiere responsabilite : vous fournissez l'infrastructure, la gerez et etes responsable des mises a jour, des correctifs de securite et des sauvegardes. Le n8n Cloud inverse ce rapport. Selon l'apercu officiel des options d'utilisation, il est entierement gere, aucune configuration n'est necessaire, et n8n se charge de la maintenance et de l'exploitation. Pour les equipes sans capacite informatique propre ou avec peu de temps pour l'entretien des serveurs, c'est un veritable avantage. Le prix a payer : vous cedez une partie du controle que vous avez consciemment acquis avec le self-hosting, et vous payez un abonnement courant au lieu de simples couts d'infrastructure.

Ce qui ne suit pas automatiquement lors du demenagement

La plus grande difference concerne les nodes. Sur le n8n Cloud, selon la documentation sur l'installation des community nodes, vous ne pouvez installer via le panneau de nodes que des community nodes verifies. Les nodes non verifies et l'installation via npm ne sont possibles qu'en self-hosted. Quiconque utilise des nodes propres ou rares doit donc verifier avant le demenagement si ces nodes sont verifies, sinon ils disparaissent purement et simplement dans le Cloud.

• Nodes : Seuls les community nodes verifies fonctionnent dans le Cloud, les installations npm et les nodes construits soi-meme restent en self-hosted.
• Identifiants : Selon la documentation d'export et d'import, les fichiers JSON de workflow exportes ne contiennent que les noms et ID des credentials, pas leurs valeurs. Apres l'import, vous devez recreer manuellement tous les identifiants.
• Configuration : Le reglage fin via des variables d'environnement, qui constitue la base de la configuration en self-hosted, n'est possible que de maniere limitee dans le Cloud, car l'instance est geree.

Limites d'execution et ressources en comparaison

En self-hosted, le nombre d'executions n'est pratiquement limite que par votre propre materiel serveur. Dans le Cloud, des quotas fixes s'appliquent selon le plan. Selon la liste de prix n8n, le plan Starter comprend 2 500 executions par mois avec 5 executions simultanees, le plan Pro 10 000 executions avec 20 executions simultanees, le plan Business 40 000 executions ainsi que SSO, SAML, LDAP et des environnements bases sur Git. Le stockage des journaux d'execution est egalement plafonne : selon les indications de la gestion des donnees Cloud, le plan Starter stocke au maximum 2 500 executions avec 7 jours de conservation, Pro jusqu'a 25 000 avec 30 jours, Enterprise jusqu'a 50 000 avec conservation illimitee. A partir de 85 pour cent d'utilisation du stockage, n8n peut nettoyer automatiquement les anciennes donnees d'execution. La memoire vive est egalement echelonnee, de 320 Mio dans le plan Starter et d'essai jusqu'a 4 096 Mio en Enterprise, alors qu'en self-hosted vous choisissez vous-meme la taille du serveur.

Ce qu'il faut concretement faire pour la migration

Les workflows peuvent etre exportes en JSON et importes dans l'instance Cloud. Avant de le faire, il vaut la peine de faire un bref etat des lieux : quels nodes sont utilises, et sont-ils tous repertories comme verifies dans le Cloud. Ensuite, les credentials sont recrees a la main dans le nouvel environnement, car, comme decrit, les fichiers exportes ne contiennent aucun secret. Quiconque a travaille jusqu'a present avec des variables d'environnement ou ses propres parametres de base de donnees devrait documenter cette configuration avant le demenagement, car elle n'existe pas sous la meme forme dans l'environnement Cloud gere. Pour les equipes qui veulent planifier le demenagement de maniere techniquement propre et avec une priorisation claire, un conseil n8n est propose, qui verifie au prealable quels workflows fonctionnent sans changement et ou des adaptations sont necessaires.

Questions frequentes sur la migration self-hosted vers Cloud chez n8n

Tous les workflows self-hosted fonctionnent-ils sans changement dans le Cloud ?

Seulement si tous les nodes utilises font partie des community nodes verifies ou sont des nodes standards n8n. Les workflows avec des nodes non verifies ou construits soi-meme doivent etre adaptes ou remplaces avant le demenagement, car, selon la documentation n8n, ils ne peuvent pas etre installes dans le Cloud.

Qu'advient-il de mes identifiants lors du demenagement ?

Ils doivent etre recrees. L'export de workflow ne contient que les noms et ID des credentials, aucun mot de passe, jeton ou cle. C'est judicieux du point de vue de la securite, mais cela signifie un effort manuel apres l'import.

Puis-je revenir plus tard au self-hosted ?

En principe, les workflows peuvent etre a nouveau exportes et importes dans une instance self-hosted. Les restrictions specifiques au Cloud disparaissent alors, mais en contrepartie vous assumez a nouveau l'entiere responsabilite de l'exploitation, des mises a jour et des sauvegardes.

Combien d'executions sont incluses dans le plan Cloud le moins cher ?

Selon la liste de prix actuelle, le plan Starter offre 2 500 executions par mois avec un maximum de 5 executions simultanees. Quiconque a besoin de plus doit passer a Pro ou Business, ou rester en self-hosted, ou la limite depend de son propre materiel serveur.