Héberger n8n sur une VM CPU : capacité, sauvegardes et coûts

Héberger n8n sur une VM CPU convient lorsque vous avez besoin de maîtriser l'environnement d'exécution, le réseau et le stockage, et qu'une personne peut exploiter le service. Dimensionnez la machine selon les workflows susceptibles de s'exécuter ensemble. Le nombre de workflows enregistrés dans l'éditeur renseigne peu sur le pic de mémoire, la durée d'exécution ou les besoins de reprise.

Ce guide aide à choisir entre n8n géré et l'auto-hébergement, à estimer la part du budget consacrée à la VM et à prévoir la persistance, les sauvegardes et la croissance. La documentation et les calculs ont été vérifiés le 11 novembre 2026. Aucun déploiement n8n, benchmark ou test de restauration n'a été exécuté pour cet article ; le dimensionnement proposé exige des mesures sur vos workflows.

Choisir le mode d'exploitation avant la VM

Choisissez n8n Cloud si vous souhaitez confier l'hébergement à n8n et si les offres disponibles répondent à vos besoins. Préférez une VM autogérée lorsque le contrôle des dépendances, de la connectivité privée ou de la configuration justifie le travail de maintenance.

Une instance CPU de Compute with Hivenet fournit l'infrastructure. Elle ne confie pas à Hivenet l'exploitation de votre application n8n, de sa base, de ses sauvegardes ou de ses workflows. Désignez une personne responsable des mises à jour, de la supervision, des identifiants et de la reprise avant d'y déplacer une automatisation critique.

Vérifiez l'édition n8n dès le départ. La comparaison officielle des éditions, en anglais, distingue les options Community gratuites des offres auto-hébergées payantes. Le partage, les secrets externes ou le stockage binaire externe peuvent influencer le choix. L'auto-hébergement n'inclut pas automatiquement toutes les fonctions payantes ; vérifiez les prix et conditions de licence actuels pour votre usage.

Adapter le CPU et la mémoire aux workflows

Considérez trois tâches différentes. Une synchronisation CRM planifiée peut surtout attendre des réponses API. Un workflow de reporting qui charge de gros jeux de données JSON peut exiger beaucoup de mémoire. Un workflow IA qui appelle un modèle distant a besoin de capacité pour coordonner les requêtes, tandis que l'inférence s'exécute ailleurs. Le fait que chaque tâche constitue un workflow ne justifie pas une estimation identique.

Pour le premier test de capacité, relevez :

• La période d'arrivée la plus chargée, y compris les horaires qui se chevauchent et les pics de webhooks.
• La taille habituelle et maximale des entrées, notamment les fichiers et grands tableaux JSON.
• Les exécutions simultanées, leur durée et le temps d'attente acceptable.
• Le pic de mémoire, l'utilisation CPU soutenue, l'activité de la base et la croissance du disque.
• Les limites des API externes, les reprises et l'effet d'une dépendance lente.

Commencez avec une petite charge représentative, puis augmentez la concurrence en observant mémoire et durée. Incluez le système, la base, le proxy inverse et les éventuels task runners dans le budget mémoire s'ils partagent la VM. N'attribuez pas toute la RAM à un seul processus.

Le guide mémoire de n8n, en anglais, cite les gros volumes de données, certains nœuds de code, les copies créées en exécution manuelle et les workflows simultanés parmi les causes de pression mémoire. Réduire la taille des lots peut être plus utile qu'acheter du CPU pour une charge limitée par la mémoire ou une API externe.

Choisir un déploiement que vous pouvez maintenir

Prenez le guide Docker Compose actuel de n8n, en anglais, comme point de départ, puis identifiez les services nécessaires. Son exemple inclut la pile de sandbox de l'Assistant IA et indique un minimum de 2 vCPU et 4 Go de RAM pour cet ensemble. Ce n'est pas un benchmark démontrant que toute charge n8n de production tient dans 4 Go.

Distinguez les besoins d'exécution des workflows des services IA facultatifs. Examinez tout composant de sandbox privilégié avant de l'intégrer en production. Fixez les versions déployées et conservez une configuration reproductible, avec les secrets hors du dépôt.

n8n prend en charge SQLite et PostgreSQL. SQLite simplifie une petite installation ; PostgreSQL ajoute une base à exploiter ou à acheter comme service. Consultez la politique actuelle de prise en charge des bases, en anglais, au moment de choisir une version. Notre guide d'hébergement PostgreSQL, en anglais, explique le choix entre une base gérée et une base que vous exploitez.

Placer n8n et PostgreSQL sur une seule VM réduit le nombre de machines, mais ils partagent la capacité et les risques de panne de cette VM. Déplacer la base ailleurs modifie les coûts et les besoins réseau ; cela ne supprime ni les sauvegardes ni les contrôles de restauration.

Prévoir les données persistantes et la récupération

Identifiez les emplacements avant le lancement : dossier utilisateur n8n, base, fichiers binaires, répertoires de nœuds personnalisés et configuration. Conserver les données lors de la recréation d'un conteneur est utile, mais ne fournit pas une copie de reprise distincte si la VM ou son disque disparaît.

Gardez la clé de chiffrement des identifiants récupérable et protégée. La documentation de la clé de chiffrement, en anglais, explique le rôle de la clé générée ou configurée. Une base restaurée contenant des identifiants chiffrés exige toujours la clé correspondante. Ne placez pas sa valeur dans un dépôt public ni dans une fiche de planification.

Suivez les consignes de sauvegarde complète, en anglais. Les exports de workflows et d'identifiants ne contiennent pas tous les éléments d'une instance. Incluez le dossier utilisateur pertinent, la base externe, les chemins personnalisés et le stockage externe. Avec SQLite, arrêtez les écritures avant une simple copie de fichier, ou utilisez une méthode qui produit une sauvegarde cohérente.

Définissez des objectifs concrets : quelle quantité de travail récent peut être perdue, et combien de temps l'automatisation peut-elle rester indisponible ? Testez la restauration dans un environnement isolé incapable d'envoyer de vraies notifications, de modifier des fiches clients ou de déclencher des paiements. Vérifiez le déchiffrement des identifiants et l'exécution d'un workflow de test sans effet réel avant de considérer la sauvegarde comme utilisable.

L'historique d'exécution consomme aussi du stockage. Choisissez les données à garder pour le diagnostic et les justificatifs, puis configurez la purge avec le guide des données d'exécution, en anglais. Surveillez ensuite l'espace réellement utilisé : supprimer des enregistrements ne réduit pas nécessairement les fichiers de base immédiatement.

Intégrer les webhooks et la supervision

Un workflow fonctionnel dans l'éditeur ne prouve pas qu'un webhook externe arrive correctement. Vérifiez DNS, HTTPS, URL publique et chemin du proxy inverse. La documentation actuelle du proxy, en anglais, utilise N8N_WEBHOOK_URL ; d'anciens exemples peuvent employer un nom déprécié. Adaptez les paramètres de confiance du proxy au chemin réel des requêtes.

Suivez les erreurs et durées des workflows ainsi que le CPU, la mémoire, le disque et la base. n8n distingue un processus joignable à /healthz d'une base prête à /healthz/readiness. Aucun des deux ne prouve qu'une API externe ou un workflow précis fonctionne. La référence de supervision, en anglais, décrit ces points d'accès et l'activation des métriques.

Prévoyez un contrôle planifié sans effet réel sur le parcours important, par exemple la lecture d'un enregistrement de test et l'écriture du résultat vers une destination dédiée. Attribuez un responsable aux notifications. Une automatisation défaillante que personne ne remarque reste défaillante.

Séparer le prix de la VM du coût d'exploitation

La page des instances CPU Hivenet, en anglais, indique 0,0175 € par vCPU-heure, avec 2 Go de RAM par vCPU et 50 Go de NVMe inclus, selon la vérification du 11 novembre 2026. Ces exemples multiplient ce tarif par 730 heures. Ils illustrent uniquement la VM, sans recommander une capacité n8n ni constituer un devis complet.

L'usage réel est facturé à la seconde et les mois n'ont pas tous la même durée. Confirmez les conditions actuelles, les taxes applicables et les frais supplémentaires avant achat. Le disque inclus sert à tout ce que vous stockez sur cette VM, notamment la croissance de la base et les journaux.

Ajoutez au budget les services de base ou de file, les sauvegardes, la supervision, les fonctions n8n payantes, les API externes et le temps d'exploitation. Par exemple, 51,10 € pour la VM, plus des hypothèses mensuelles de 8 € de sauvegarde, 20 € d'API et deux heures d'exploitation à 60 €, donnent 199,10 €. Seul le tarif VM provient de la page citée ; les autres montants sont fictifs et les coûts omis restent à ajouter. L'objectif est de rendre les coûts visibles, pas de promettre une économie universelle par rapport à n8n Cloud.

Ajouter le mode file d'attente quand les mesures le justifient

Si les exécutions s'accumulent malgré une configuration adaptée sur une seule instance, examinez le mode file d'attente de n8n, en anglais. Il sépare le processus principal des workers d'exécution et utilise Redis pour coordonner le travail. Les workers ont besoin d'un accès compatible à la base et de la même clé de chiffrement. Ce mode ajoute des composants à superviser, mettre à jour et restaurer.

Vérifiez le traitement des fichiers avant de déplacer des workflows riches en données binaires. Le mode file d'attente ne permet pas leur persistance sur le système de fichiers local, et le stockage externe dépend de l'édition n8n. La documentation du stockage externe, en anglais, distingue aussi la prise en charge officielle des services compatibles S3 à valider séparément. Un bucket quelconque ou un montage local ne suffit pas à achever cette conception.

Davantage de workers sur la même VM partagent toujours son CPU et sa RAM. Ils ne créent ni matériel supplémentaire ni haute disponibilité pour cette VM. Identifiez d'abord si la limite concerne la concurrence d'exécution, la mémoire, la base ou un service en aval.

Décider à partir d'un test d'acceptation

Avant de dépendre du service, vérifiez la charge de pointe représentative, la réception des webhooks externes, la persistance après redémarrage, une restauration isolée et le comportement face aux erreurs API. Consignez la version n8n, les fonctions activées, la taille de la VM, la rétention et le responsable des incidents.

Utilisez les consignes de mise à jour n8n, en anglais, pour préparer les changements. Effectuez une sauvegarde complète, testez la version cible et tenez compte des migrations de base ; revenir à une ancienne image ne les annule pas nécessairement. Une VM CPU convient lorsque la charge mesurée et les responsabilités restent gérables. Si personne n'assume ces responsabilités, choisissez un hébergement géré avant d'optimiser une faible différence de prix serveur.