Sommaire
En bref
- Un projet n8n synology suppose une image compatible avec Linux amd64 ou arm64, un modèle admis par Container Manager et une version de DSM conforme à ses prérequis.
- Préparez avant l’installation le port 5678, un dossier persistant monté sur
/home/node/.n8n, la clé de chiffrement, le fuseau horaire et, si nécessaire, PostgreSQL.- Pour un accès distant, placez un proxy inversé HTTPS devant n8n. N’exposez pas directement le port 5678 sur Internet.
- Sauvegardez ensemble les données, la base éventuelle et la clé. Une sauvegarde dont la restauration n’a jamais été testée reste une hypothèse.
- Le NAS convient à une charge maîtrisée si une personne assume la supervision, les reprises sur erreur et les montées de version.
Avant de déployer n8n synology, décrivez le travail actuel. Qui déclenche le processus, combien de fois par semaine, quelles données entrent, quelles applications répondent et que se passe-t-il si une exécution échoue pendant plusieurs heures ? Cette vue métier décide si le NAS constitue un hébergement raisonnable.
Un processus fréquent, stable et réversible peut justifier une instance n8n auto-hébergée. Un traitement rare, rempli d’exceptions ou dépendant d’une disponibilité que personne ne surveille crée surtout une nouvelle charge d’exploitation. Le bénéfice apparent s’efface alors derrière les sauvegardes, les mises à jour et les incidents.
En bref
L’installation tient si six conditions sont réunies avant la mise en production :
- Le processeur du NAS correspond à une image officielle Linux amd64 ou arm64.
- Le modèle et la version de DSM acceptent une version compatible de Synology Container Manager.
- Les données n8n sortent du conteneur grâce à un volume persistant.
- L’accès distant passe par un dispositif maîtrisé, généralement un proxy inversé DSM avec TLS ou un VPN.
- La clé de chiffrement et la base entrent dans la sauvegarde.
- Un responsable consulte les journaux, surveille les ressources et sait reprendre une exécution échouée.
La documentation n8n ne fixe aucun minimum universel de CPU ou de mémoire. La charge dépend du volume JSON, des fichiers binaires, du nombre de noeuds et des exécutions simultanées. Il faut donc mesurer sur un workflow représentatif.
n8n synology : vérifier la compatibilité avant l’installation
Vérifier une architecture Linux amd64 ou arm64
En 2026, le tag latest de l’image officielle n8nio/n8n publie des variantes Linux amd64 et arm64. Vérifiez l’architecture du processeur du NAS, puis la présence du modèle dans la liste de compatibilité de Container Manager. Le nom commercial du NAS ne suffit pas.
Cette vérification précède tout téléchargement. Une architecture absente de l’image officielle bloque le déploiement, même si DSM fonctionne correctement.
Faire correspondre DSM et la version de Container Manager
Container Manager impose ses propres prérequis DSM. Ces conditions évoluent : contrôlez les notes de version de Container Manager pour votre modèle avant de modifier DSM.
Inventorier les ressources déjà consommées par le NAS
Mesurez la mémoire, le CPU et le réseau pendant les sauvegardes, l’indexation et les autres tâches lourdes du NAS. Container Manager affiche ces statistiques pour les conteneurs et les projets actifs.
Cette mesure compte davantage qu’un seuil générique, que la documentation ne fournit pas. Un workflow qui manipule des pièces jointes volumineuses ou lance plusieurs exécutions en parallèle peut épuiser la mémoire, alors qu’un traitement séquentiel de petits objets reste léger.
Le NAS ne doit pas devenir moins fiable pour héberger son automatisation. S’il approche déjà ses limites aux heures chargées, retenez un hébergement séparé ou la version infogérée.
Préparer l’adresse locale ou le nom de domaine, le port 5678 et le stockage
Réunissez avant le déploiement :
- l’adresse locale du NAS ;
- un nom de domaine si l’instance doit recevoir des webhooks externes ;
- un port hôte disponible relié au port 5678 du conteneur ;
- un dossier Synology persistant ;
- une valeur
GENERIC_TIMEZONEadaptée aux horaires métier ; - une clé
N8N_ENCRYPTION_KEYconservée hors du seul NAS ; - les paramètres PostgreSQL si vous retenez cette base ;
- la méthode d’accès, locale, VPN ou proxy inversé HTTPS.
Ce cadrage évite de reconstruire le conteneur à chaque découverte tardive.
Décider si le NAS est le bon hébergement pour n8n
Décrire qui exécute le processus, à quelle fréquence et avec quelles données
Prenez un processus concret. Notez son déclencheur actuel, sa fréquence hebdomadaire, les données lues et écrites, les personnes qui traitent les exceptions et l’effet d’un doublon ou d’un retard.
Une automatisation rentable retire un travail répétitif dont les règles tiennent dans le temps. Si chaque dossier exige une interprétation humaine différente, n8n déplacera la difficulté vers une suite de branches fragiles.
Choisir entre instance auto-hébergée et version infogérée
Le choix porte sur la responsabilité d’exploitation.
Une instance auto-hébergée sur Synology conserve la maîtrise du conteneur, du stockage et du réseau. Elle oblige en retour l’équipe à sécuriser l’accès, préserver la clé, surveiller les ressources, sauvegarder les données et conduire chaque montée de version.
La version infogérée réduit cette charge d’infrastructure. Elle ne supprime ni le cadrage des workflows, ni la gestion des authentifications, ni la recette des reprises sur erreur.
Retenez le NAS lorsque son exploitation entre clairement dans le rôle d’une personne identifiée. Si personne ne peut restaurer l’instance un jour ouvré ordinaire, déplacez cette responsabilité vers une offre infogérée ou un hébergement administré séparément.
Identifier les processus trop rares ou trop instables pour être automatisés
Renoncez, ou limitez le périmètre, lorsque :
- le traitement revient rarement et prend peu de temps ;
- ses règles changent plus vite que le workflow ;
- la majorité des dossiers finit en exception manuelle ;
- aucune API stable ne relie les applications ;
- le NAS porte déjà des services prioritaires et manque de marge ;
- personne n’assume la maintenance.
Un formulaire mieux conçu ou une procédure courte peut coûter moins cher à maintenir qu’un workflow.
Fixer les responsabilités de supervision et de reprise
Attribuez quatre responsabilités : recevoir l’alerte, qualifier l’incident, décider d’une reprise et valider le résultat métier. Conservez pour chaque exécution un identifiant de corrélation, l’étape atteinte et les données nécessaires à une relance contrôlée.
En cas d’échec, le workflow doit arrêter les écritures dépendantes, enregistrer le contexte et prévenir la personne désignée. La reprise automatique ne convient qu’aux opérations répétables sans doublon.
Installer n8n sur Synology avec un projet Compose
Un projet Docker Compose rend la configuration lisible, reproductible et révisable. Un conteneur créé uniquement dans l’assistant graphique peut convenir à un essai, mais il expose moins clairement les choix lors d’une reconstruction.
Créer le dossier persistant dans DSM
Avec un compte administrateur, ouvrez Panneau de configuration > Dossier partagé > Créer > Créer un dossier partagé. Choisissez le stockage, puis créez un sous-dossier réservé aux données n8n.
Accordez au conteneur les droits nécessaires sur ce seul emplacement. Évitez d’étendre une autorisation d’écriture à tout le dossier partagé.
Récupérer l’image officielle n8nio/n8n
Dans le Registre de Container Manager, recherchez n8nio/n8n, sélectionnez l’image officielle et téléchargez un tag précis. Docker Hub sert de registre par défaut.
Un tag fixé rend la recette et le retour vers une configuration connue plus traçables que latest.
Définir le port, le volume et le fuseau horaire
Dans Container Manager > Project, créez un projet, indiquez son nom et son répertoire de travail, puis chargez ou saisissez le fichier docker-compose.yml. Une base cohérente ressemble à ceci :
services:
n8n:
image: n8nio/n8n:VERSION_VALIDEE
restart: unless-stopped
ports:
- "5678:5678"
environment:
- GENERIC_TIMEZONE=Europe/Berlin
- N8N_ENCRYPTION_KEY=${N8N_ENCRYPTION_KEY}
volumes:
- /volume1/chemin/n8n-data:/home/node/.n8nLa valeur du tag doit correspondre à la version recettée. Le chemin hôte dépend de votre volume Synology. Placez la clé dans un mécanisme protégé adapté à votre exploitation, sans la publier avec le fichier Compose.
Monter le stockage Synology sur /home/node/.n8n
Le montage vers /home/node/.n8n conserve notamment la configuration et, avec SQLite, le fichier de base. Sans ce volume, supprimer puis recréer le conteneur peut emporter les données stockées à l’intérieur.
Contrôlez le chemin et ses droits avant le premier démarrage.
Démarrer le projet et contrôler son état dans Container Manager
Terminez l’assistant en demandant le démarrage du projet. Dans Container > Action > Details, vérifiez :
- l’état du conteneur ;
- l’absence de redémarrages répétés ;
- les journaux de démarrage ;
- la consommation de mémoire et de CPU ;
- le montage du volume ;
- l’écoute du port choisi.
Si le service s’arrête, lisez le journal avant de relancer. Un redémarrage automatique peut masquer une erreur de permission ou une pression mémoire.
Ouvrir l’interface sur l’adresse locale du NAS
Depuis un poste du réseau local, ouvrez http://ADRESSE_DU_NAS:5678. La documentation Docker indique http://localhost:5678 pour une installation locale ; sur le NAS, utilisez l’adresse effectivement joignable.
Les sources fournies ne décrivent pas les champs de création du compte propriétaire à la première ouverture. Suivez donc l’interface de la version installée et ne transposez pas une procédure ancienne.
Configurer HTTPS et les webhooks derrière le proxy inversé DSM
L’accès distant réclame d’abord un nom d’hôte, un certificat, une règle réseau et une décision sur les ports exposés. Le bénéfice arrive ensuite : l’éditeur, les redirections et les webhooks utilisent une URL publique cohérente.
Créer la règle HTTPS vers le port interne 5678
Dans DSM 7, ouvrez Panneau de configuration > Portail de connexion > Avancé > Proxy inversé. Créez une source HTTPS avec le nom d’hôte public, puis une destination HTTP vers l’adresse interne du NAS et le port 5678.
Gardez le port 5678 interne. Une exposition directe de ce port sur Internet élargit inutilement la surface accessible.
Obtenir et associer un certificat Let’s Encrypt
Dans Panneau de configuration > Sécurité > Certificat, demandez un certificat Let’s Encrypt pour le domaine, puis associez-le au service du proxy inversé.
Pour un domaine personnalisé, Synology demande que le port 80 soit transféré vers le NAS afin d’émettre et de renouveler le certificat. Cette condition ne s’applique pas de la même manière au service Synology DDNS. N’ouvrez que les ports requis, avec des règles de pare-feu explicites.
Renseigner N8N_HOST, N8N_PROTOCOL et N8N_PROXY_HOPS
Derrière un seul proxy inversé DSM, configurez notamment :
environment:
- N8N_HOST=n8n.exemple.fr
- N8N_PROTOCOL=https
- N8N_PORT=5678
- N8N_PROXY_HOPS=1N8N_PROXY_HOPS doit refléter le nombre réel de proxies de confiance. Une chaîne comprenant un autre intermédiaire exige donc une valeur adaptée, sans copier mécaniquement 1.
Utiliser N8N_WEBHOOK_URL à partir de n8n 2.35.0
Ajoutez l’URL publique explicite :
environment:
- N8N_WEBHOOK_URL=https://n8n.exemple.fr/N8N_WEBHOOK_URL remplace WEBHOOK_URL, désormais dépréciée. Une ancienne configuration peut encore produire un avertissement dans les journaux. La documentation n8n du proxy inversé détaille ce changement.
Tester les redirections et les webhooks depuis le réseau réellement utilisé
Testez depuis l’extérieur si le service doit recevoir des appels externes. Vérifiez l’ouverture de l’éditeur, une redirection d’authentification et un webhook de recette. Confirmez que les URL produites portent le bon domaine et https.
Pour un usage strictement interne, gardez l’accès local ou passez par un VPN. Le VPN exige ses propres règles de pare-feu et n’ouvre que ses ports de connexion. Le tunnel intégré à n8n sert au développement local ; la documentation le déconseille en production.
Si un test échoue, conservez la requête, son heure et l’identifiant de corrélation. Suspendez le processus concerné jusqu’à ce que l’URL publique et le routage aient été vérifiés.
Rendre les données n8n persistantes et restaurables
Conserver le dossier .n8n hors du conteneur
Le dossier /home/node/.n8n doit survivre à la suppression du conteneur. Son montage sur le stockage Synology conserve la configuration locale et la base SQLite par défaut.
Le volume ne remplace pas une sauvegarde. Une suppression du dossier hôte, une panne du volume ou une corruption toucheraient toujours les données.
Fixer et protéger N8N_ENCRYPTION_KEY
Au premier lancement, n8n génère par défaut une clé et l’enregistre dans ~/.n8n. Vous pouvez fixer N8N_ENCRYPTION_KEY avant ce lancement pour maîtriser sa conservation.
Sauvegardez cette valeur dans un emplacement séparé et protégé. Sans la clé du fichier de configuration ou la même N8N_ENCRYPTION_KEY, une base restaurée et les identifiants chiffrés qu’elle contient restent indéchiffrables.
Choisir SQLite pour un usage limité ou PostgreSQL pour une architecture plus structurée
SQLite constitue la base par défaut et stocke son fichier dans ~/.n8n/database.sqlite. Il garde le déploiement compact pour un usage limité et une concurrence faible.
PostgreSQL sépare davantage le service applicatif de ses données. Il ajoute toutefois une base à administrer, sauvegarder, surveiller et mettre à jour. La configuration passe par DB_TYPE=postgresdb, puis par les variables de base, d’hôte, de port, d’utilisateur, de mot de passe et de schéma.
En juillet 2026, n8n documente PostgreSQL 17 et 18 comme versions activement maintenues, avec PostgreSQL 16 en compatibilité. Cette plage suivra le cycle de maintenance de PostgreSQL.
Sauvegarder SQLite à l’arrêt ou par instantané cohérent
Arrêtez n8n avant de copier SQLite, ou utilisez un mécanisme d’instantané qui garantit la cohérence du fichier. Une copie effectuée pendant une écriture peut produire une sauvegarde inutilisable.
Conservez ensemble le dossier .n8n, la clé et la définition Compose correspondante. Lors d’un échec de sauvegarde, déclenchez une alerte et ne marquez pas le point de restauration comme valide.
Sauvegarder PostgreSQL avec le volume n8n et la clé
Avec PostgreSQL, sauvegardez trois ensembles synchronisés :
- la base PostgreSQL ;
- le volume n8n ;
- la clé de chiffrement.
Ajoutez la configuration nécessaire pour reconstruire les connexions sans y exposer les secrets. Une sauvegarde partielle ne reconstitue pas forcément les authentifications ni l’état attendu.
Effectuer une recette de restauration avant la mise en production
Restaurez dans un environnement de préproduction isolé. Ouvrez les workflows, contrôlez les authentifications, lancez une exécution de test et vérifiez les webhooks.
Documentez l’ordre des opérations et le résultat. Si la restauration échoue, le processus métier doit rester arrêté ou suivre une procédure manuelle connue jusqu’à correction.
Dimensionner les workflows pour la charge du NAS Synology
Choisir entre workflow unique et workflows découpés
Un workflow unique simplifie un petit enchaînement atomique. Il devient pénible à reprendre quand il mélange collecte, transformation, appels externes et écritures irréversibles.
Découpez les traitements longs ou difficiles à rejouer. Chaque partie reçoit alors une entrée claire, un identifiant de corrélation et une règle de reprise. Ce découpage ajoute des interfaces à maintenir, mais il évite de recommencer toute la chaîne après une panne tardive.
Préférer une règle déterministe à un modèle de langage quand les critères sont stables
Une règle explicite convient à des critères stables : format, statut, seuil métier ou présence d’un champ. Elle se teste, se relit et produit le même résultat pour la même entrée.
Un modèle de langage peut traiter une ambiguïté réelle, mais il ajoute une dépendance externe, une variation de réponse et une consommation à surveiller. Prévoyez alors une validation, un journal des entrées et sorties autorisées et une voie manuelle en cas d’échec. Le NAS n’absorbe pas cette incertitude par magie.
Comparer traitement synchrone et file d’attente
Le traitement synchrone garde une chaîne simple : le déclencheur attend le résultat. Il convient aux opérations courtes dont la charge reste maîtrisée. Une indisponibilité en aval prolonge cependant l’exécution et retient des ressources.
Une file d’attente découple la réception et le traitement. Elle devient pertinente lorsque les arrivées concurrentes doivent être lissées ou reprises. Elle ajoute des composants, des états intermédiaires et une supervision propre. Ne l’introduisez que si la concurrence mesurée le justifie.
Quand un traitement échoue, la file doit conserver le message ou l’envoyer vers une voie d’erreur, sans relance infinie.
Limiter la taille des données binaires et les exécutions simultanées
Évitez de transporter des fichiers volumineux à travers de nombreux noeuds si une référence contrôlée suffit. Limitez la concurrence tant que les mesures CPU et mémoire n’ont pas établi une marge.
Un conteneur qui redémarre sous pression mémoire interrompt les exécutions en cours. Le redémarrage automatique remet le service debout, mais il ne répare pas le traitement métier abandonné.
Définir un identifiant de corrélation et une reprise sur erreur
Générez ou conservez un identifiant stable dès l’entrée. Inscrivez-le dans les appels sortants, les journaux et les alertes lorsque les systèmes connectés le permettent.
Classez ensuite les erreurs :
- une erreur transitoire peut subir quelques reprises espacées ;
- une erreur de données exige une correction avant relance ;
- une écriture dont le résultat reste inconnu impose une vérification avant toute répétition ;
- une erreur durable arrête la chaîne et alerte un technicien.
Cette discipline évite qu’une reprise fabrique des doublons.
Superviser n8n dans Synology Container Manager
Activer une politique de redémarrage adaptée
Container Manager peut redémarrer automatiquement un conteneur. Activez une politique compatible avec l’exploitation, puis surveillez le nombre de redémarrages.
Un conteneur qui boucle doit finir par attirer une intervention. Sinon, le redémarrage masque la panne et consomme les ressources du NAS.
Suivre CPU, mémoire, réseau et redémarrages
Dans Action > Details, consultez les statistiques CPU, mémoire et réseau. Observez-les pendant un workflow représentatif, puis pendant les autres tâches lourdes du NAS.
Fixez vos seuils après cette mesure. La documentation ne fournit pas de minimum matériel universel ni de seuil adapté à tous les workflows.
Envoyer les journaux vers la console ou un fichier
N8N_LOG_OUTPUT accepte notamment console ou file pour la journalisation ordinaire des éditions auto-hébergées. Container Manager affiche et exporte les journaux du conteneur.
Conservez une durée adaptée à vos besoins de diagnostic sans saturer le stockage. Le streaming de journaux documenté par n8n relève de l’édition Enterprise, ce qui le distingue de ces sorties ordinaires.
Alerter sur les échecs de workflow sans créer de boucle d’erreur
Une alerte utile contient le workflow, l’heure, l’identifiant de corrélation, l’étape en échec et un lien vers le contexte disponible. Envoyez-la par un canal distinct du système défaillant lorsque la criticité l’exige.
Le mécanisme d’alerte doit lui-même échouer proprement. Évitez qu’un workflow d’erreur relance sa propre alerte sans limite.
Documenter la reprise et l’escalade vers un technicien
Pour chaque workflow en production, écrivez :
- ce qui s’arrête lors d’un échec ;
- quelles données restent conservées ;
- ce qui peut être relancé automatiquement ;
- ce qui exige une vérification humaine ;
- qui reçoit l’escalade ;
- comment constater que la reprise a réussi.
La supervision observe l’incident. La procédure de reprise protège le processus métier.
Diagnostiquer les pannes courantes de n8n sur un NAS Synology
Le conteneur s’arrête avec une erreur de permission
Ouvrez Container Manager > Container > Details > Settings > Volume Settings. Contrôlez le chemin monté et ses permissions, puis rendez-les cohérentes avec celles du dossier dans File Station.
Si une autorisation Everyone en lecture-écriture devient nécessaire, Synology recommande de la limiter au seul sous-dossier monté. N’élargissez pas ces droits au dossier partagé entier.
Le port choisi est déjà utilisé par DSM
Un conflit de port peut provoquer des erreurs de service. Modifiez le port hôte dans Compose tout en gardant le port interne 5678, puis adaptez la destination du proxy inversé.
Contrôlez ensuite le démarrage, les journaux et l’accès local avant de remettre les webhooks en service.
L’interface HTTPS répond mais les redirections sont incorrectes
Vérifiez N8N_HOST, N8N_PROTOCOL, N8N_PORT, l’URL publique et N8N_PROXY_HOPS. Contrôlez aussi l’association du certificat au bon service DSM.
Recettez une authentification qui déclenche une redirection. Une page d’accueil accessible ne prouve pas que les retours externes utilisent le bon domaine.
Un webhook produit une URL interne ou erronée
Contrôlez N8N_WEBHOOK_URL, ou l’ancienne variable WEBHOOK_URL si la version précède son remplacement. Migrez vers N8N_WEBHOOK_URL.
Les sources établissent les variables à configurer, mais ne donnent pas de procédure précise pour afficher la valeur effective de l’URL de webhook. Vérifiez donc l’URL présentée dans le workflow et testez-la depuis le réseau réel, sans prétendre qu’un contrôle documentaire plus précis existe.
Le conteneur redémarre sous pression mémoire
Consultez les statistiques de Container Manager et les journaux autour du redémarrage. Reproduisez ensuite le traitement avec moins de concurrence et des données plus petites.
Si la charge reste excessive, découpez le workflow, réduisez les données binaires ou déplacez l’instance. L’auto-redémarrage seul laisse les exécutions interrompues dans un état qu’il faut qualifier.
Une exécution échoue après l’appel d’une API métier
Recherchez l’identifiant de corrélation dans n8n et, lorsque l’API le permet, dans le système distant. Déterminez si l’écriture a échoué, réussi ou laissé un résultat inconnu.
Ne relancez automatiquement que les opérations conçues pour supporter une répétition. Dans le doute, arrêtez la suite, conservez le contexte et demandez une validation humaine.
Mettre à jour n8n sur Synology sans perdre les données
Éviter le tag latest pour une production maîtrisée
latest facilite un essai, mais masque la version réellement recettée lors d’un téléchargement ultérieur. Fixez un tag précis dans Compose et consignez la version déployée.
La documentation fournie n’établit aucune procédure d’alerte périodique lors de la publication d’une nouvelle version. Inscrivez donc une vérification régulière des notes de version dans la responsabilité d’exploitation, sans présenter cette vérification comme une fonction native documentée.
Sauvegarder le volume, la base et la clé avant la montée de version
Avant toute montée de version, sauvegardez le dossier .n8n, la base PostgreSQL éventuelle et N8N_ENCRYPTION_KEY. Vérifiez que le point de restauration s’ouvre dans un environnement isolé.
Lisez ensuite les notes de version et repérez les changements incompatibles. Une image téléchargeable ne prouve pas que vos workflows resteront inchangés.
Tester la nouvelle image dans un environnement de préproduction
Recréez une instance séparée avec une copie cohérente des données et la version ciblée. Bloquez ses déclencheurs externes ou redirigez-les vers des systèmes de recette afin d’éviter des écritures réelles.
Surveillez le démarrage, les migrations, la mémoire et les journaux. Arrêtez la montée de version si les données ou les authentifications ne se restaurent pas correctement.
Recréer le conteneur avec les mêmes montages persistants
Container Manager sait actualiser le tag d’une image. Avec Compose, récupérez l’image validée puis recréez le conteneur en conservant le volume externe et les mêmes variables nécessaires.
La suppression du conteneur ne doit jamais viser le dossier persistant. Vérifiez ce montage dans le résumé avant de confirmer l’opération.
Recetter les workflows, authentifications et webhooks
Testez au moins un chemin nominal, un échec contrôlé et une reprise pour chaque workflow critique. Vérifiez les horaires, les identifiants enregistrés, les redirections et les webhooks depuis leur réseau d’origine.
Surveillez les premières exécutions réelles. Si une anomalie apparaît, stoppez les déclencheurs concernés et conservez le contexte avant toute nouvelle tentative.
Préparer un retour fondé sur une sauvegarde cohérente
Docker peut récupérer un ancien tag, arrêter et supprimer le conteneur, puis le recréer avec les mêmes options. Cette mécanique ne garantit pas qu’une base migrée par une version plus récente reste compatible avec l’ancienne.
Les sources fournies ne documentent aucune restauration universellement sûre après une telle migration. Le retour doit donc reposer sur la sauvegarde cohérente prise avant la montée de version, restaurée selon une procédure déjà recettée.
n8n synology en 2026 : installer sans fragiliser le NAS
Un NAS Synology peut héberger n8n lorsque son processeur, DSM et Container Manager acceptent l’image officielle, que la charge garde une marge mesurée et qu’une personne assume l’exploitation. Le volume persistant, la clé de chiffrement, la base, HTTPS, les journaux et la reprise sur erreur forment un seul dispositif. En retirer un élément fragilise l’ensemble.
Si le NAS porte déjà des services prioritaires, si le processus cumule les exceptions ou si personne ne conduit les sauvegardes et les montées de version, choisissez la version infogérée ou un hébergement séparé.
L’étape suivante consiste à sélectionner un workflow représentatif, mesurer sa charge en préproduction et restaurer sa sauvegarde. Exposez l’instance et confiez-lui un processus critique seulement après cette recette.