n8n self-hosted : guide d'installation, sécurisation et mise en production pour PME

Self-hoster n8n est devenu, en 2026, le choix par défaut des PME qui veulent garder le contrôle sur leurs workflows d'automatisation et leurs données. Le coût mensuel est imbattable (15 à 60 €/mois pour la majorité des usages PME), la facture ne dérive pas avec le nombre d'utilisateurs, et la souveraineté est totale. Mais self-hoster sans méthode expose à trois risques sérieux : perte de données par mauvaise gestion des sauvegardes, intrusion par configuration de sécurité bâclée, et indisponibilité chronique faute de monitoring. Ce guide détaille les deux déploiements les plus pertinents pour une PME (Docker Compose sur VPS et Azure Container Apps), avec les configurations concrètes, les bonnes pratiques de sécurisation et les pratiques de mise en production qui distinguent un n8n bricolé d'un n8n d'entreprise.

Cet article s'adresse aux DSI, lead développeurs, et responsables IT de PME qui ont décidé (ou envisagent) de déployer n8n en self-hosted plutôt que d'utiliser n8n Cloud. Si vous n'êtes pas encore convaincu du choix de n8n, nous avons traité la question dans notre comparatif n8n vs Make vs Zapier vs Power Automate et notre guide d'introduction à n8n pour DSI. Si vous êtes là, c'est que le débat est tranché et que la question concrète est : comment faire ça bien.

On va couvrir : les quatre options d'hébergement réalistes pour une PME et comment choisir, le walkthrough complet sur Docker Compose (cas le plus courant), le walkthrough complet sur Azure Container Apps (notre choix chez Lumivi), la sécurisation au niveau attendu en production, et les pratiques opérationnelles qui font la différence à 6 et 12 mois.

Le prérequis honnête : self-hoster n8n demande des compétences

n8n recommande explicitement le self-hosting aux utilisateurs avertis. Cette recommandation n'est pas du marketing pour pousser n8n Cloud c'est un avertissement légitime. Les compétences réelles requises :

• Administration Linux de base (utilisateurs, permissions, services systemd, firewall)
• Docker et Docker Compose au niveau confortable (volumes, networks, environment variables, healthchecks)
• Configuration d'un reverse proxy (Caddy ou Traefik ou nginx) avec gestion automatique des certificats SSL
• Configuration d'une base PostgreSQL et compréhension des sauvegardes
• Notions de sécurité réseau (ports ouverts, fail2ban, audit logs)
• Lecture de logs et debug sous pression

Si votre équipe IT n'a pas ces compétences en interne et que vous n'avez pas de partenaire technique de confiance, n8n Cloud reste le bon choix. Le coût mensuel supérieur est largement compensé par l'absence de risque opérationnel. Si vos compétences sont présentes ou si vous avez un partenaire qui prend la main, continuez la lecture.

Les quatre options d'hébergement réalistes pour une PME

Avant de choisir, voici la matrice de décision honnête.

n8n Cloud

L'option managée, hébergée par n8n. Pas d'installation, pas de maintenance, mise à jour automatique. Tarification à partir de 20 € par mois pour le plan Starter (2 500 exécutions actives/mois) et de l'ordre de 50 € pour le plan Pro (10 000 exécutions). Au-delà, les plans Business commencent à 667 € par mois.

Choisir n8n Cloud si : vous n'avez pas de compétences DevOps en interne, vos workflows traitent moins de 10 000 exécutions par mois, vos données ne sont pas particulièrement sensibles, et le budget « par exécution » n'est pas un blocage. C'est aussi la bonne option pour faire un POC sans s'engager sur l'infrastructure.

Docker Compose sur VPS (Hetzner, OVH, Scaleway)

Le déploiement le plus répandu et probablement le mieux documenté. Un serveur virtuel chez un fournisseur cloud européen, Docker Compose pour orchestrer n8n + PostgreSQL + reverse proxy, gestion manuelle (ou semi-automatisée) des sauvegardes et des mises à jour.

Coût indicatif : un VPS Hetzner CPX21 (3 vCPU, 4 Go RAM, 80 Go SSD, trafic 20 To) coûte environ 8,50 € HT/mois. OVH propose des VPS Comfort à environ 12 € HT/mois. Scaleway DEV1-M à 15 € HT/mois. Sauvegardes et stockage objet S3 pour la persistance : compter 3 à 8 € supplémentaires. Total : 12 à 25 € HT/mois pour une instance n8n production pour PME.

Choisir cette option si : vous avez les compétences DevOps en interne, vous voulez maîtriser totalement les coûts, vos données doivent rester en Europe, vous n'avez pas besoin d'auto-scaling agressif. C'est l'option par défaut pour 70 % des PME que nous accompagnons.

Azure Container Apps

L'option PaaS de Microsoft pour déployer des conteneurs avec auto-scaling natif, intégration Azure Key Vault pour les secrets, Azure Database for PostgreSQL Flexible Server pour la base, gestion automatique du certificat SSL, et facturation à la consommation. C'est notre choix chez Lumivi.

Coût indicatif : sur le profil Consumption (workload élastique), comptez 30 à 80 € HT/mois pour une PME avec usage modéré (n8n auto-scale de 0 à 2-3 instances selon la charge, PostgreSQL Flexible Server en Burstable B1ms à environ 13 € HT/mois, stockage et networking marginaux). Sur profil Dedicated avec instances toujours actives (Dedicated-D4), comptez 150 à 250 € HT/mois.

Choisir cette option si : vous êtes déjà sur Azure pour votre infrastructure, vous voulez profiter de l'intégration native avec Azure Key Vault, Azure Monitor et Azure AI services (Azure OpenAI Service en particulier), vous préférez payer un peu plus pour ne pas gérer l'OS du serveur, et vous voulez de l'auto-scaling sans configuration complexe. C'est aussi la bonne option pour les PME en démarrage qui anticipent une croissance rapide.

Kubernetes (AKS, GKE, EKS)

L'option enterprise pour la haute disponibilité multi-instances, le déploiement multi-régions, l'intégration GitOps complète. Compter 300 à 800 € HT/mois au minimum pour un cluster AKS ou GKE de petite taille.

Choisir cette option si : vous êtes une ETI ou un grand compte avec un département DevOps mature, vous avez besoin de haute disponibilité (uptime > 99,9 %), vos workflows n8n sont critiques pour des opérations métier en temps réel. Pour une PME standard, Kubernetes est presque toujours du surdimensionnement. N'y allez pas par effet de mode.

La matrice de décision synthétique

Cas 1 : Docker Compose sur VPS, pas à pas

Ce cas couvre l'installation production-ready sur un VPS Linux Ubuntu 24.04 LTS, avec n8n derrière Caddy comme reverse proxy (Caddy gère automatiquement les certificats Let's Encrypt), PostgreSQL en base de données, et sauvegardes automatisées vers un stockage objet S3-compatible.

Étape 1 : provisionnement du VPS

Chez OVH Cloud par exemple, créer une instance en Ubuntu 24.04, clé SSH ajoutée à la création. Coût : ~12 €/mois HT.

Configurer immédiatement le DNS pour pointer votre sous-domaine vers l'IP du VPS. Par exemple, créer un A record n8n.votreentreprise.com qui pointe vers l'IP publique. Sans DNS correctement propagé, Caddy ne pourra pas obtenir le certificat SSL.

Étape 2 : sécurisation initiale du serveur

Se connecter en SSH puis créer un utilisateur non-root avec sudo, désactiver le login root par mot de passe, n'autoriser que la clé SSH.

# Création utilisateur
adduser deploy
usermod -aG sudo deploy
rsync --archive --chown=deploy:deploy ~/.ssh /home/deploy

# Désactiver login root et password auth dans /etc/ssh/sshd_config
sudo sed -i 's/^#PermitRootLogin.*/PermitRootLogin no/' /etc/ssh/sshd_config
sudo sed -i 's/^#PasswordAuthentication.*/PasswordAuthentication no/' /etc/ssh/sshd_config
sudo systemctl restart ssh

# Firewall basique
sudo ufw allow OpenSSH
sudo ufw allow 80/tcp
sudo ufw allow 443/tcp
sudo ufw enable

# Installer fail2ban pour limiter le brute-force SSH
sudo apt update && sudo apt install -y fail2ban
sudo systemctl enable fail2ban && sudo systemctl start fail2ban

Étape 3 : installation de Docker et Docker Compose

# Installation officielle Docker pour Ubuntu 24.04
curl -fsSL https://get.docker.com -o get-docker.sh
sudo sh get-docker.sh
sudo usermod -aG docker deploy
newgrp docker

# Vérification
docker --version
docker compose version

Étape 4 : génération des secrets et création du docker-compose.yml

Tous les secrets doivent être générés une seule fois et stockés en lieu sûr. La clé d'encryption en particulier (N8N_ENCRYPTION_KEY) est critique : si vous la perdez, tous les credentials stockés dans n8n deviennent irrécupérables.

mkdir -p ~/n8n && cd ~/n8n
mkdir -p caddy_data caddy_config n8n_data postgres_data
chmod 700 n8n_data postgres_data

# Génération des secrets
openssl rand -hex 32  # Pour N8N_ENCRYPTION_KEY
openssl rand -hex 32  # Pour POSTGRES_PASSWORD
openssl rand -hex 16  # Pour POSTGRES_NON_ROOT_PASSWORD

Créer un fichier .env (à conserver impérativement en dehors du repo Git si vous versionnez votre stack) :

# Domaine
DOMAIN_NAME=n8n.votreentreprise.com
SUBDOMAIN=n8n
GENERIC_TIMEZONE=Europe/Paris

# Secrets - REMPLACER par les valeurs générées plus haut
N8N_ENCRYPTION_KEY=<32_octets_hex_generes>
POSTGRES_USER=n8n
POSTGRES_PASSWORD=<32_octets_hex_generes>
POSTGRES_DB=n8n

# Email pour Let's Encrypt
SSL_EMAIL=admin@votreentreprise.com

Créer le docker-compose.yml :

services:
  postgres:
    image: postgres:16-alpine
    restart: unless-stopped
    environment:
      POSTGRES_USER: ${POSTGRES_USER}
      POSTGRES_PASSWORD: ${POSTGRES_PASSWORD}
      POSTGRES_DB: ${POSTGRES_DB}
    volumes:
      - ./postgres_data:/var/lib/postgresql/data
    healthcheck:
      test: ['CMD-SHELL', 'pg_isready -U ${POSTGRES_USER} -d ${POSTGRES_DB}']
      interval: 10s
      timeout: 5s
      retries: 5

  n8n:
    image: docker.n8n.io/n8nio/n8n:latest
    restart: unless-stopped
    depends_on:
      postgres:
        condition: service_healthy
    environment:
      - DB_TYPE=postgresdb
      - DB_POSTGRESDB_HOST=postgres
      - DB_POSTGRESDB_PORT=5432
      - DB_POSTGRESDB_DATABASE=${POSTGRES_DB}
      - DB_POSTGRESDB_USER=${POSTGRES_USER}
      - DB_POSTGRESDB_PASSWORD=${POSTGRES_PASSWORD}
      - N8N_HOST=${DOMAIN_NAME}
      - N8N_PORT=5678
      - N8N_PROTOCOL=https
      - WEBHOOK_URL=https://${DOMAIN_NAME}/
      - N8N_ENCRYPTION_KEY=${N8N_ENCRYPTION_KEY}
      - GENERIC_TIMEZONE=${GENERIC_TIMEZONE}
      - N8N_LOG_LEVEL=info
      - N8N_SECURE_COOKIE=true
      - N8N_PROXY_HOPS=1
      - EXECUTIONS_DATA_PRUNE=true
      - EXECUTIONS_DATA_MAX_AGE=336  # 14 jours
    volumes:
      - ./n8n_data:/home/node/.n8n

  caddy:
    image: caddy:2-alpine
    restart: unless-stopped
    ports:
      - '80:80'
      - '443:443'
    volumes:
      - ./Caddyfile:/etc/caddy/Caddyfile
      - ./caddy_data:/data
      - ./caddy_config:/config
    depends_on:
      - n8n

Créer un Caddyfile minimaliste (Caddy gère automatiquement le certificat SSL) :

{$DOMAIN_NAME} {
    reverse_proxy n8n:5678
    encode gzip
    
    header {
        Strict-Transport-Security "max-age=31536000; includeSubDomains; preload"
        X-Content-Type-Options "nosniff"
        X-Frame-Options "SAMEORIGIN"
        Referrer-Policy "strict-origin-when-cross-origin"
    }
}

Étape 5 : démarrage et accès initial

docker compose up -d
docker compose logs -f n8n

Une fois les logs stables (chercher la ligne Editor is now accessible via), ouvrir https://n8n.votreentreprise.com dans le navigateur. Créer le compte owner avec un mot de passe fort, c'est l'administrateur global de l'instance.

Étape 6 : sauvegardes automatisées

Sans sauvegarde, vous n'êtes pas en production. Voici un script de sauvegarde quotidienne vers un bucket S3-compatible (exemple Hetzner Object Storage, mais fonctionne avec Scaleway, OVH ou AWS S3) :

# Installer awscli configuré pour le bucket S3-compatible
sudo apt install -y awscli
aws configure  # avec les credentials du bucket

# Créer le script /usr/local/bin/n8n-backup.sh
sudo tee /usr/local/bin/n8n-backup.sh > /dev/null <<'EOF'
#!/bin/bash
set -e
BACKUP_DIR="/tmp/n8n-backup"
DATE=$(date +%Y%m%d_%H%M%S)
BUCKET="votre-bucket-backup"

mkdir -p $BACKUP_DIR
cd /home/deploy/n8n

# Dump PostgreSQL
docker compose exec -T postgres pg_dump -U n8n n8n | gzip > $BACKUP_DIR/n8n_db_$DATE.sql.gz

# Archive du dossier n8n_data (credentials chiffrés, settings)
tar czf $BACKUP_DIR/n8n_data_$DATE.tar.gz n8n_data/

# Upload vers S3
aws s3 cp $BACKUP_DIR/n8n_db_$DATE.sql.gz s3://$BUCKET/db/ --endpoint-url https://fsn1.your-objectstorage.com
aws s3 cp $BACKUP_DIR/n8n_data_$DATE.tar.gz s3://$BUCKET/data/ --endpoint-url https://fsn1.your-objectstorage.com

# Nettoyage local
rm -rf $BACKUP_DIR

# Rotation : garder 30 jours
aws s3 ls s3://$BUCKET/db/ --endpoint-url https://fsn1.your-objectstorage.com | \
  awk '{print $4}' | head -n -30 | xargs -I {} aws s3 rm s3://$BUCKET/db/{} --endpoint-url https://fsn1.your-objectstorage.com
EOF

sudo chmod +x /usr/local/bin/n8n-backup.sh

# Crontab : sauvegarde quotidienne à 3h du matin
echo "0 3 * * * /usr/local/bin/n8n-backup.sh >> /var/log/n8n-backup.log 2>&1" | crontab -

Test de restauration : à faire au moins une fois. Une sauvegarde non testée n'est pas une sauvegarde. Provisionnez un VPS de test, restaurez la dernière sauvegarde, vérifiez que vos workflows s'exécutent. Cette procédure prend 2 heures et vaut son pesant d'or le jour où votre instance principale tombe.

Étape 7 : mises à jour

n8n publie une version mineure toutes les semaines. Procédure de mise à jour propre :

cd ~/n8n
# Sauvegarde manuelle avant montée de version
/usr/local/bin/n8n-backup.sh

# Pull et redémarrage
docker compose pull
docker compose up -d

# Vérifier les logs
docker compose logs -f n8n --tail=100

Notre recommandation : ne pas pinner la version sur latest en production. Préférez une version précise (ex: docker.n8n.io/n8nio/n8n:1.78.2), testez les montées de version sur un environnement de staging, puis basculez en production. n8n est mature mais des régressions arrivent.

Cas 2 : Azure Container Apps, pas à pas

C'est notre choix chez Lumivi. L'intérêt principal par rapport au VPS Docker Compose : Azure gère l'auto-scaling, le SSL, les secrets via Key Vault, et la base PostgreSQL est un service managé. Moins d'opérations, plus de coût en run, mais beaucoup plus simple à exploiter sur la durée.

Prérequis

• Un abonnement Azure actif
• Azure CLI installé localement (az --version doit fonctionner)
• Un domaine personnalisé avec accès au DNS

Étape 1 : configuration de base et resource group

# Authentification
az login
az account set --subscription "<votre-subscription-id>"

# Variables
RESOURCE_GROUP="rg-n8n-prod"
LOCATION="francecentral"
ENV_NAME="n8n-env"
APP_NAME="n8n"
KEYVAULT_NAME="kv-n8n-prod"
POSTGRES_NAME="psql-n8n-prod"
DB_NAME="n8n"
DB_ADMIN_USER="n8nadmin"
DB_PASSWORD=$(openssl rand -base64 24)
N8N_ENCRYPTION_KEY=$(openssl rand -hex 32)

# Resource group
az group create --name $RESOURCE_GROUP --location $LOCATION

# Enregistrement des providers nécessaires
az provider register --namespace Microsoft.App
az provider register --namespace Microsoft.OperationalInsights
az provider register --namespace Microsoft.DBforPostgreSQL
az provider register --namespace Microsoft.KeyVault

Étape 2 : Azure Key Vault pour les secrets

az keyvault create \
  --name $KEYVAULT_NAME \
  --resource-group $RESOURCE_GROUP \
  --location $LOCATION \
  --enable-rbac-authorization true

# Stocker les secrets
az keyvault secret set --vault-name $KEYVAULT_NAME --name "db-password" --value "$DB_PASSWORD"
az keyvault secret set --vault-name $KEYVAULT_NAME --name "n8n-encryption-key" --value "$N8N_ENCRYPTION_KEY"

Étape 3 : PostgreSQL Flexible Server

az postgres flexible-server create \
  --resource-group $RESOURCE_GROUP \
  --name $POSTGRES_NAME \
  --location $LOCATION \
  --admin-user $DB_ADMIN_USER \
  --admin-password "$DB_PASSWORD" \
  --sku-name Standard_B1ms \
  --tier Burstable \
  --storage-size 32 \
  --version 16 \
  --public-access 0.0.0.0

az postgres flexible-server db create \
  --resource-group $RESOURCE_GROUP \
  --server-name $POSTGRES_NAME \
  --database-name $DB_NAME

Le Standard_B1ms (1 vCPU, 2 Go RAM) suffit largement pour une PME jusqu'à plusieurs milliers d'exécutions n8n par jour. Compter environ 13 € HT/mois pour cette taille.

Étape 4 : Container Apps Environment

# Création du Log Analytics workspace (auto par az containerapp env)
az containerapp env create \
  --name $ENV_NAME \
  --resource-group $RESOURCE_GROUP \
  --location $LOCATION

Étape 5 : déploiement du Container App n8n

DB_HOST="${POSTGRES_NAME}.postgres.database.azure.com"

az containerapp create \
  --name $APP_NAME \
  --resource-group $RESOURCE_GROUP \
  --environment $ENV_NAME \
  --image docker.n8n.io/n8nio/n8n:latest \
  --target-port 5678 \
  --ingress external \
  --min-replicas 1 \
  --max-replicas 3 \
  --cpu 1.0 \
  --memory 2.0Gi \
  --env-vars \
    DB_TYPE=postgresdb \
    DB_POSTGRESDB_HOST=$DB_HOST \
    DB_POSTGRESDB_PORT=5432 \
    DB_POSTGRESDB_DATABASE=$DB_NAME \
    DB_POSTGRESDB_USER=$DB_ADMIN_USER \
    DB_POSTGRESDB_PASSWORD=secretref:db-password \
    DB_POSTGRESDB_SSL_ENABLED=true \
    DB_POSTGRESDB_SSL_REJECT_UNAUTHORIZED=false \
    N8N_ENCRYPTION_KEY=secretref:n8n-encryption-key \
    N8N_HOST=n8n.votreentreprise.com \
    N8N_PORT=5678 \
    N8N_PROTOCOL=https \
    WEBHOOK_URL=https://n8n.votreentreprise.com/ \
    N8N_SECURE_COOKIE=true \
    N8N_PROXY_HOPS=1 \
    GENERIC_TIMEZONE=Europe/Paris \
    EXECUTIONS_DATA_PRUNE=true \
    EXECUTIONS_DATA_MAX_AGE=336 \
  --secrets \
    db-password=keyvaultref:https://${KEYVAULT_NAME}.vault.azure.net/secrets/db-password,identityref:system \
    n8n-encryption-key=keyvaultref:https://${KEYVAULT_NAME}.vault.azure.net/secrets/n8n-encryption-key,identityref:system \
  --system-assigned

Étape 6 : autoriser l'identité managée à lire le Key Vault

PRINCIPAL_ID=$(az containerapp show --name $APP_NAME --resource-group $RESOURCE_GROUP --query identity.principalId -o tsv)

az role assignment create \
  --assignee $PRINCIPAL_ID \
  --role "Key Vault Secrets User" \
  --scope $(az keyvault show --name $KEYVAULT_NAME --query id -o tsv)

Étape 7 : configuration du domaine custom et SSL

Récupérer le hostname par défaut de l'application :

APP_FQDN=$(az containerapp show --name $APP_NAME --resource-group $RESOURCE_GROUP --query properties.configuration.ingress.fqdn -o tsv)
echo "App FQDN: $APP_FQDN"

Créer un CNAME dans votre DNS pour faire pointer n8n.votreentreprise.com vers $APP_FQDN. Puis lier le custom domain à l'app (Azure va automatiquement émettre un certificat) :

az containerapp hostname add \
  --hostname n8n.votreentreprise.com \
  --name $APP_NAME \
  --resource-group $RESOURCE_GROUP

az containerapp hostname bind \
  --hostname n8n.votreentreprise.com \
  --name $APP_NAME \
  --resource-group $RESOURCE_GROUP \
  --environment $ENV_NAME \
  --validation-method CNAME

Étape 8 : sauvegardes managées

PostgreSQL Flexible Server fait des sauvegardes automatiques (7 jours de rétention par défaut, configurable jusqu'à 35 jours). C'est suffisant pour la base. Pour aller plus loin, configurer un export quotidien vers un Storage Account :

az postgres flexible-server backup create \
  --resource-group $RESOURCE_GROUP \
  --server-name $POSTGRES_NAME \
  --backup-name "manual-$(date +%Y%m%d)"

Pour le volume n8n (configurations, custom nodes éventuels), Azure Container Apps ne gère pas nativement la persistance hors base. Si vous installez des custom nodes ou utilisez des fichiers locaux, monter un Azure Files share. Pour 95 % des usages PME, la base PostgreSQL suffit (workflows et credentials y sont stockés chiffrés).

Étape 9 : monitoring

Activer Application Insights et lier au Log Analytics workspace du Container Apps Environment. Les logs sont automatiquement collectés. Configurer des alertes sur :

• Taux d'échec des exécutions n8n > 5 % sur 15 minutes
• Latence moyenne des webhooks > 2 secondes
• CPU PostgreSQL > 80 % sur 10 minutes
• Échec de l'application (replicas à 0 pendant > 5 minutes)

Sécurisation : les pratiques attendues en production

Que vous soyez sur Docker Compose ou sur Azure Container Apps, certaines pratiques sont incontournables pour une utilisation en production.

Gestion des secrets

Ne jamais stocker N8N_ENCRYPTION_KEY, mots de passe DB, ou clés API en clair dans le docker-compose.yml ou dans des variables d'environnement non-protégées. Sur VPS Docker Compose, utilisez un fichier .env avec permissions 600 (lecture/écriture propriétaire uniquement) et exclu de tout repo Git. Sur Azure, utilisez Key Vault systématiquement avec des secretref.

Authentification

n8n supporte plusieurs mécanismes d'authentification en self-hosted. Pour une PME, l'authentification email/password native est suffisante au démarrage, mais activez 2FA (TOTP) sur les comptes admin dès la première semaine. Pour les déploiements à 10+ utilisateurs, configurer SAML/OIDC (intégration Microsoft Entra ID, Google Workspace, Okta) devient pertinent, c'est dispo dans l'édition Community avec quelques limitations, et complet en Enterprise.

Politique RBAC

n8n Community supporte le rôle de base. Pour différencier admin / éditeur / lecteur sur les workflows, il faut soit l'édition Enterprise, soit organiser via plusieurs instances n8n par périmètre (option viable pour une PME avec 2-3 équipes distinctes mais lourde au-delà).

Audit logs

n8n loggue les exécutions en base. Pour une vraie traçabilité (qui a modifié quel workflow, quand), activer N8N_LOG_LEVEL=info minimum, exporter les logs vers un système centralisé (Loki + Grafana sur VPS, Azure Monitor sur Azure), et conserver au moins 90 jours.

Restriction réseau

Ne pas exposer n8n publiquement si vos workflows n'ont pas besoin de webhooks externes. Sur Azure Container Apps, configurer ingress internal au lieu d'external et accéder via VPN ou Azure Front Door avec WAF. Sur VPS, utiliser Cloudflare Access ou Tailscale Funnel pour ne pas exposer le 443 en direct.

Si vous avez besoin de webhooks externes (typique : recevoir des callbacks de Stripe, HubSpot, etc.), gardez l'ingress public mais activez systématiquement la signature des webhooks côté n8n et vérifiez-la dans chaque workflow concerné.

Mises à jour de sécurité

n8n publie régulièrement des patches de sécurité. Souscrire au GitHub Security Advisory de n8n-io/n8n et appliquer les patches critiques sous 48 heures. Les patches mineurs : à chaque cycle de maintenance (toutes les 2-4 semaines).

Gestion des credentials externes

n8n stocke les credentials des services tiers (API keys Stripe, tokens OAuth, etc.) chiffrés dans sa base avec N8N_ENCRYPTION_KEY. C'est solide, mais ça implique deux choses :

• La clé d'encryption doit être sauvegardée séparément de la base (sinon un attaquant qui dump la base déchiffre tout)
• Pour les credentials très sensibles (clés API production, tokens admin), envisager d'externaliser dans un secret manager (Azure Key Vault, HashiCorp Vault, AWS Secrets Manager) et de les passer à n8n en runtime via des variables d'environnement

Mise en production : ce qui distingue un n8n bricolé d'un n8n d'entreprise

Au-delà de l'installation et de la sécurité, voici les pratiques opérationnelles que nous mettons systématiquement en place chez nos clients.

Versioning des workflows

Activer la source control integration de n8n (Git) pour versionner les workflows. Chaque modification importante part en commit, code review possible, rollback possible. Indispensable dès que plusieurs personnes éditent des workflows.

Environnement de staging

Une instance n8n production et une instance n8n staging avec la même configuration. Tout nouveau workflow ou modification majeure passe d'abord par staging, est testé, puis poussé en prod via Git. Pas négociable pour des workflows qui touchent à la facturation, aux notifications clients, ou à l'envoi d'emails commerciaux.

Healthchecks et alertes proactives

Au-delà du monitoring infrastructure, ajouter des healthchecks au niveau workflow : un workflow planifié qui s'auto-vérifie toutes les 5 minutes et envoie une alerte Slack/Teams si une dépendance critique (base de données, API externe) ne répond pas. Le coût en temps de développement est négligeable et la valeur est énorme en cas d'incident.

Documentation des workflows

Chaque workflow doit avoir, dans son nom et dans une note interne : son propriétaire métier, sa criticité (P1/P2/P3), la fréquence d'exécution attendue, le contact en cas de problème. Un n8n avec 200 workflows et zéro documentation devient ingérable en 6 mois.

Pruning des données d'exécution

Activer EXECUTIONS_DATA_PRUNE=true et configurer EXECUTIONS_DATA_MAX_AGE (336 heures = 14 jours dans les exemples ci-dessus) pour éviter que la base PostgreSQL grossisse sans contrôle. Pour les exécutions critiques, exporter avant pruning vers un stockage de log dédié.

Plan de continuité

Documenter le RTO (Recovery Time Objective) et le RPO (Recovery Point Objective) cibles. Pour une PME avec n8n en production :

• RPO acceptable : 24 heures (sauvegarde quotidienne)
• RTO acceptable : 4 heures (restauration depuis backup + redémarrage)

Si vos workflows sont critiques au point où ces objectifs ne suffisent pas, vous avez probablement besoin d'une architecture HA (Kubernetes ou Azure Container Apps avec replicas multiples + PostgreSQL HA), et l'arbitrage économique devient celui d'une ETI, pas d'une PME.

Notre stack chez Lumivi : Azure Container Apps avec mises à jour mensuelles

Pour notre instance n8n interne (sourcing prospects, automatisations commerciales, scripts d'analyse), nous avons retenu Azure Container Apps avec PostgreSQL Flexible Server, principalement pour quatre raisons :

1. Zero ops sur l'OS. Pas de patches Linux, pas de mises à jour kernel, pas de gestion du fail2ban. Azure prend tout en charge.

2. Intégration native Azure AI. Notre stack mélange n8n et Azure OpenAI Service pour certains workflows. L'authentification via Managed Identity élimine la gestion des clés API.

3. Auto-scaling élastique. Le profil Consumption permet de descendre à 1 replica la nuit et de scaler à 3 sur les pics. La facture suit l'usage réel.

4. Sauvegarde managée PostgreSQL. 7 jours de PITR (Point-In-Time Recovery) automatique, c'est largement au-dessus de ce qu'on bricolerait sur VPS sans y consacrer du temps.

Le coût mensuel total pour notre instance (n8n + PostgreSQL + Key Vault + Log Analytics) est de l'ordre de 45-55 € HT/mois, ce qui est cohérent avec un VPS Docker Compose plus un peu de temps DevOps qu'on n'a pas à dépenser.

Cela dit, nous recommandons Docker Compose sur VPS à la majorité de nos clients PME, pour deux raisons : le coût d'entrée est plus bas (15-25 € HT/mois), et la stack est plus portable si le client veut un jour changer de fournisseur. Notre choix Azure est un choix de prestataire qui consomme aussi du Azure pour d'autres briques (Azure OpenAI Service notamment) pour une PME qui n'a pas cette dépendance, le VPS reste le bon défaut.

Conclusion : la production, c'est l'exploitation, pas l'installation

L'installation de n8n self-hosted est l'étape facile. Une heure de Docker Compose ou deux heures d'Azure CLI suffisent pour avoir un n8n qui répond. Ce qui distingue un déploiement amateur d'un déploiement professionnel, c'est ce qui se passe les 11 mois suivants : sauvegardes testées, monitoring actif, mises à jour disciplinées, versioning des workflows, alertes calibrées, documentation tenue, plan de continuité documenté.

Une PME qui investit 2-3 jours dans l'installation initiale et 30 minutes par semaine dans l'exploitation aura un n8n robuste qui supporte plusieurs années d'usage productif. Une PME qui installe en 2 heures et n'y revient qu'en panique tous les 6 mois aura, statistiquement, perdu des données, vécu des indisponibilités, et finira par penser que « le self-hosted ça ne marche pas » alors que c'est la pratique d'exploitation qui n'a pas suivi.

Le coût de l'infrastructure n'est pas le coût total. Sur un VPS à 15 € HT/mois, le coût caché vrai d'une instance n8n bien exploitée est plutôt de l'ordre de 80-150 € de temps DevOps mensuel équivalent. Sur Azure Container Apps à 50 € HT/mois, ce coût tombe à 30-60 € équivalent. Cette différence justifie souvent le choix Azure pour les PME qui n'ont pas d'expertise DevOps interne dédiée.

Chez Lumivi, nous déployons et exploitons des instances n8n self-hosted pour des PME et ETI d'Auvergne-Rhône-Alpes, en Docker Compose ou Azure Container Apps selon le contexte. Si vous voulez un avis sur votre architecture cible, ou un accompagnement pour mettre en production sans tâtonner, notre diagnostic gratuit de 30 minutes est le bon point de départ.

À lire également : n8n : qu'est-ce que c'est ? Le guide complet pour DSI et responsables IT · n8n vs Make vs Zapier vs Power Automate : le comparatif honnête 2026 · Assistant IA interne et RAG : pourquoi votre PME en a besoin