Auto-héberger n8n sur AWS pour une automatisation conforme au RGPD

Chaque tutoriel n8n sur internet s'arrête à "et maintenant vous pouvez accéder à l'UI sur le port 5678". Très bien pour bricoler. Pas bien quand les workflows que vous allez construire vont déplacer des données clients, synchroniser des commandes vers votre ERP, et vivre dans un périmètre RGPD.

Ce guide, c'est le setup de production que nous déployons pour les clients européens qui ont besoin d'automatisation auto-hébergée avec une vraie résidence des données. Il couvre ce que la plupart des tutoriels zappent : backend PostgreSQL, sauvegardes automatisées, SSL avec renouvellement, durcissement de l'environnement, et un déploiement qui survit vraiment à un reboot.

Si vous n'êtes pas encore sûr que n8n auto-hébergé est le bon choix face à n8n Cloud, Zapier ou Make, commencez par notre comparatif n8n vs Zapier vs Make.

Pourquoi AWS et pas n'importe quel VPS

Réponse honnête : pour la majorité des clients, un VPS Hetzner ou Scaleway suffit et coûte moins cher. Nous choisissons AWS quand :

• Le client opère déjà d'autres infrastructures sur AWS et veut une facturation, un IAM et des logs unifiés
• La conformité requiert des certifications spécifiques (HIPAA, SOC 2, ISO 27001) qu'AWS publie pour des régions précises
• L'automatisation a besoin d'une intégration serrée avec d'autres services AWS (S3, Lambda, RDS)
• Le scaling prévisible compte plus que le coût mensuel le plus bas

Si ces critères ne s'appliquent pas, le même setup tourne sur n'importe quel VPS compatible Docker avec des changements mineurs. C'est le pattern qui compte, pas le cloud.

L'architecture que nous déployons

Le setup est volontairement ennuyeux. L'ennuyeux scale, l'ennuyeux échoue de manière prévisible, l'ennuyeux c'est ce que vous voulez à 2h du matin.

Pour les clients plus volumineux, nous déplaçons PostgreSQL vers RDS et ajoutons un Application Load Balancer en façade. Pour la plupart des clients qui démarrent, tout tourne sur un t3.small unique avec PostgreSQL dans un container voisin. La migration vers RDS plus tard est directe.

Étape 1 : provisionner l'instance EC2

Dans la console AWS, dashboard EC2, lancez une nouvelle instance avec ces réglages :

• AMI : Ubuntu Server 24.04 LTS (dernière LTS, patches de sécurité supportés jusqu'en 2029).
• Type d'instance : t3.small pour les démarrages de production. Évitez t3.micro pour quoi que ce soit de sérieux, le plafond 1GB de RAM va vous rattraper sous charge.
• Région : eu-west-3 (Paris) pour les clients français, eu-central-1 (Francfort) pour les allemands, ca-central-1 (Montréal) pour les cas PHIPA canadiens.
• Stockage : volume EBS gp3 de 30GB. Largement de quoi loger PostgreSQL et les images Docker, plus de la marge pour les logs d'exécution.
• Key pair : créer un nouveau, télécharger le .pem, le stocker dans un gestionnaire de mots de passe. Ne jamais l'envoyer par mail.
• Security group : autoriser en entrée TCP 22 (SSH, restreint à votre IP), 80 (HTTP, pour le provisioning SSL de Caddy), 443 (HTTPS). Ne pas exposer 5678 publiquement.
• Elastic IP : en allouer une et l'associer à l'instance. Sans ça, l'IP publique change à chaque redémarrage et casse votre DNS.

Une fois l'instance démarrée, pointez un enregistrement DNS A (du genre automation.votreentreprise.com) vers l'Elastic IP. Attendez la propagation DNS avant de continuer. Caddy a besoin que le domaine résolve correctement avant de pouvoir provisionner SSL.

Étape 2 : installer Docker et préparer l'environnement

Connectez-vous en SSH et installez Docker plus Docker Compose :

# Mise à jour des paquets
sudo apt update && sudo apt upgrade -y

# Installation de Docker
curl -fsSL https://get.docker.com | sudo sh

# Ajoutez votre utilisateur au groupe docker (pour éviter sudo à chaque commande)
sudo usermod -aG docker $USER
newgrp docker

# Installation du plugin Docker Compose
sudo apt install -y docker-compose-plugin

# Vérification
docker --version && docker compose version

Créez le répertoire de travail et la structure :

mkdir -p ~/n8n/{data,db,caddy/data,caddy/config,backups}
cd ~/n8n

Étape 3 : écrire la configuration Docker Compose

Voici le fichier compose de production que nous utilisons. PostgreSQL en Docker pour le setup de démarrage. SSL automatique via Caddy.

# ~/n8n/docker-compose.yml
services:
  postgres:
    image: postgres:16-alpine
    restart: always
    environment:
      POSTGRES_USER: n8n
      POSTGRES_PASSWORD: ${POSTGRES_PASSWORD}
      POSTGRES_DB: n8n
    volumes:
      - ./db:/var/lib/postgresql/data
    healthcheck:
      test: ["CMD-SHELL", "pg_isready -U n8n -d n8n"]
      interval: 10s
      timeout: 5s
      retries: 5
    networks:
      - n8n-net

  n8n:
    image: n8nio/n8n:latest
    restart: always
    depends_on:
      postgres:
        condition: service_healthy
    environment:
      DB_TYPE: postgresdb
      DB_POSTGRESDB_HOST: postgres
      DB_POSTGRESDB_PORT: 5432
      DB_POSTGRESDB_DATABASE: n8n
      DB_POSTGRESDB_USER: n8n
      DB_POSTGRESDB_PASSWORD: ${POSTGRES_PASSWORD}
      N8N_HOST: ${N8N_HOST}
      N8N_PORT: 5678
      N8N_PROTOCOL: https
      WEBHOOK_URL: https://${N8N_HOST}/
      N8N_ENCRYPTION_KEY: ${N8N_ENCRYPTION_KEY}
      GENERIC_TIMEZONE: Europe/Paris
      N8N_DEFAULT_BINARY_DATA_MODE: filesystem
      N8N_RUNNERS_ENABLED: true
      N8N_BLOCK_ENV_ACCESS_IN_NODE: true
      N8N_DIAGNOSTICS_ENABLED: false
    volumes:
      - ./data:/home/node/.n8n
    networks:
      - n8n-net

  caddy:
    image: caddy:2-alpine
    restart: always
    ports:
      - "80:80"
      - "443:443"
    volumes:
      - ./Caddyfile:/etc/caddy/Caddyfile
      - ./caddy/data:/data
      - ./caddy/config:/config
    depends_on:
      - n8n
    networks:
      - n8n-net

networks:
  n8n-net:
    driver: bridge

Le Caddyfile est volontairement minuscule :

# ~/n8n/Caddyfile
{$N8N_HOST} {
    reverse_proxy n8n:5678
    encode gzip
}

Et les secrets dans .env :

# ~/n8n/.env (NE JAMAIS commiter ce fichier)
POSTGRES_PASSWORD=$(openssl rand -base64 32)
N8N_ENCRYPTION_KEY=$(openssl rand -hex 32)
N8N_HOST=automation.votreentreprise.com

Générez de vraies valeurs pour le mot de passe et la clé de chiffrement (les commandes openssl produisent des vrais secrets, remplacez les lignes par la sortie). Verrouillez le fichier :

chmod 600 ~/n8n/.env

Étape 4 : démarrer et vérifier

Tout démarrer :

cd ~/n8n
docker compose up -d
docker compose ps

Les trois containers doivent être en Up sous environ 60 secondes. Caddy va demander le certificat SSL à Let's Encrypt la première fois que quelqu'un atteint le port 443 avec votre hostname. Suivez les logs :

docker compose logs -f caddy

Vous devriez voir un message de provisioning de certificat réussi. Allez sur https://automation.votreentreprise.com, complétez l'assistant de configuration n8n avec votre compte admin, et vous avez une instance fonctionnelle.

Étape 5 : configurer les sauvegardes automatisées

C'est l'étape que la plupart des guides "self-host n8n" zappent et que la plupart des clients regrettent d'avoir zappée. Deux choses à sauvegarder :

1. La base de données PostgreSQL (workflows, credentials, historique d'exécutions)
2. Le répertoire ~/n8n/data (fichiers binaires, état spécifique aux nodes)

Écrivez un script de sauvegarde :

# ~/n8n/backup.sh
#!/usr/bin/env bash
set -euo pipefail

BACKUP_DIR=~/n8n/backups
TIMESTAMP=$(date -u +%Y%m%d-%H%M%S)
S3_BUCKET=s3://votre-bucket-backups/n8n

# Dump base de données
docker compose -f ~/n8n/docker-compose.yml exec -T postgres \
  pg_dump -U n8n n8n | gzip > "${BACKUP_DIR}/db-${TIMESTAMP}.sql.gz"

# Fichiers
tar -czf "${BACKUP_DIR}/data-${TIMESTAMP}.tar.gz" -C ~/n8n data

# Upload S3 (chiffré côté serveur)
aws s3 cp "${BACKUP_DIR}/db-${TIMESTAMP}.sql.gz" "${S3_BUCKET}/" \
  --sse AES256
aws s3 cp "${BACKUP_DIR}/data-${TIMESTAMP}.tar.gz" "${S3_BUCKET}/" \
  --sse AES256

# Rétention 30 jours en local, S3 gère sa propre lifecycle
find "${BACKUP_DIR}" -name "db-*.sql.gz" -mtime +30 -delete
find "${BACKUP_DIR}" -name "data-*.tar.gz" -mtime +30 -delete

echo "Backup ${TIMESTAMP} terminé"

Rendez-le exécutable et planifiez-le toutes les nuits via cron :

chmod +x ~/n8n/backup.sh
crontab -e
# Ajoutez la ligne :
# 30 2 * * * /home/ubuntu/n8n/backup.sh >> /home/ubuntu/n8n/backup.log 2>&1

Pour S3, l'instance EC2 a besoin d'un rôle IAM avec accès en écriture à votre bucket de sauvegarde. Mettez en place une lifecycle policy sur le bucket pour expirer les sauvegardes de plus de 90 jours, sauf si une exigence de conformité impose une rétention plus longue.

Étape 6 : durcir la posture de sécurité

Le minimum que nous livrons à chaque client :

• SSH : désactiver complètement l'authentification par mot de passe, accès par clé uniquement. Éditer /etc/ssh/sshd_config, mettre PasswordAuthentication no, redémarrer sshd.
• Pare-feu : configurer UFW pour n'autoriser que 22 (depuis l'IP du bureau), 80, 443. Tout le reste est droppé. sudo ufw enable.
• Fail2ban : installer et configurer pour bloquer les tentatives de brute-force SSH. sudo apt install fail2ban.
• Mises à jour de sécurité automatiques : sudo apt install unattended-upgrades et activer pour les patches de sécurité uniquement.
• Authentification n8n : activer le 2FA sur chaque compte utilisateur, pas seulement admin. Définir une politique de mot de passe forte dans les réglages n8n.
• Base de données : PostgreSQL n'est accessible que depuis le réseau Docker interne. Confirmer avec docker compose port postgres 5432 qui ne doit rien retourner de public.
• Logs : configurer l'agent CloudWatch ou simplement expédier les logs Docker vers S3 avec une politique de rotation. Rétention 90 jours pour la réponse aux incidents.

Étape 7 : considérations spécifiques RGPD

C'est la partie que vous ne trouverez pas dans la doc n8n et la partie que les clients européens demandent le plus.

Résidence des données : choisissez une région UE (eu-west-3 Paris, eu-central-1 Francfort) pour l'instance EC2, le volume EBS, le bucket S3 de sauvegarde, et toute base de données RDS. Documentez ça dans votre DPA. Chaque octet de donnée client traité par n8n reste à l'intérieur de l'UE.

Sous-traitants : en auto-hébergeant, vous avez éliminé n8n l'entreprise comme sous-traitant de votre automatisation. Le seul sous-traitant dans ce setup est AWS lui-même, qui est facile à lister et qui a un DPA publié que vous pouvez référencer.

Droit à l'effacement : construisez dans n8n un workflow qui, à partir d'un ID client, supprime les données de ce client sur l'ensemble de vos systèmes connectés. Testez-le. Ce n'est plus optionnel dans les schémas d'application de l'article 17 du RGPD.

Contrat de sous-traitance : quand n8n traite des données personnelles pour le compte de clients (par exemple, dans un contexte SaaS B2B), vos propres clients peuvent vous demander un DPA. Le setup ci-dessus vous donne la fondation technique, le texte juridique est un exercice séparé mais beaucoup plus simple quand le flux de données est clair.

Logs d'audit : activez la fonctionnalité d'audit log de n8n (tier payant) ou superposez la vôtre via CloudWatch. Vous devez pouvoir répondre à "qui a accédé à cette credential, et quand" si un régulateur le demande.

À quoi ressemble le résultat en exploitation

Une fois tout en place, vous avez :

• Une URL unique (https://automation.votreentreprise.com) où l'équipe se connecte
• Une instance EC2 qui coûte environ 20 à 30€/mois incluant le stockage et la bande passante
• Des sauvegardes nocturnes chiffrées sur S3 avec une rétention documentée de 30 jours
• Une résidence complète des données en UE
• Aucun coût à l'exécution, aucune facture surprise, aucun vendor lock-in

Nous faisons tourner exactement ce setup pour des clients en France, en Allemagne et au Canada depuis plus de 18 mois. L'indisponibilité totale non planifiée sur toutes les instances cumulées est sous 4 heures, causée une fois par une mauvaise mise à jour manuelle que nous nous sommes infligée à nous-mêmes. Le setup lui-même est ennuyeux et c'est le plus beau compliment qu'une infrastructure puisse recevoir.

FAQ

Combien de temps ce déploiement prend-il en pratique ?

Un premier déploiement à partir de zéro, c'est une demi-journée à une journée pour un ingénieur à l'aise avec Docker et AWS. Nous le faisons pour les clients en environ 4 heures, DNS, provisioning SSL, première salve de workflows de test et durcissement de sécurité inclus. La maintenance courante, c'est environ 1 à 2 heures par mois si vous restez à jour sur les versions n8n.

Faut-il RDS ou PostgreSQL en Docker suffit ?

PostgreSQL en Docker suffit vraiment jusqu'à environ 100k exécutions par mois, à condition d'avoir le script de sauvegarde qui tourne et qui est testé. Nous migrons les clients vers RDS quand le volume d'exécution passe au-dessus de ~200k/mois, quand ils ont besoin de point-in-time recovery, ou quand leur équipe sécurité veut la séparation opérationnelle entre l'app et la base. La migration prend 2 à 4 heures, import des données et changements Docker Compose inclus.

Que se passe-t-il quand n8n publie une mise à jour ?

Tirer la nouvelle image et recréer le container. La cadence recommandée est mensuelle, sur une fenêtre à faible trafic :

cd ~/n8n
docker compose pull
docker compose up -d

Avant l'upgrade, prendre une sauvegarde fraîche. Lire le changelog n8n pour les breaking changes. Nous avons rencontré une casse peut-être deux fois en 18 mois sur l'ensemble des instances clientes et les deux étaient rollback en moins de 10 minutes.

Peut-on utiliser ce setup hors UE ?

Oui. L'architecture est agnostique de la région. Pour les clients canadiens nous déployons sur ca-central-1 (Montréal) pour la PIPEDA / PHIPA. Pour les clients US, us-east-1 ou us-west-2. Le fichier Docker Compose ne change pas, seule la région AWS change.

Et le scaling au-delà d'une instance EC2 ?

n8n supporte un déploiement en queue-mode avec plusieurs containers workers lisant depuis une queue Redis, ce qui permet de scaler horizontalement. Nous le déployons pour les clients qui dépassent les 500k exécutions/mois ou avec des workflows sensibles à la latence. Pour la majorité des clients, un seul t3.small ou t3.medium gère le volume pendant des années.

Pourquoi Caddy et pas Nginx ?

Les deux fonctionnent. Nous choisissons Caddy parce que la configuration est un fichier de quatre lignes et que le provisioning SSL est entièrement automatique, sans scripts certbot à maintenir. Nginx est un bon choix si votre équipe le connaît déjà et a des configs standardisées. Le résultat final est le même.

Est-ce surdimensionné pour une petite équipe qui automatise quelques workflows ?

Sous les 5 000 exécutions mensuelles, n8n Cloud à 20-25€/mois est probablement le meilleur compromis. L'auto-hébergement gagne sa place quand le volume d'exécution, les exigences de conformité ou le nombre de workflows vous pousse au-delà de cette barre. Nous migrons les clients vers le self-hosted quand leur facture Cloud dépasse 80€/mois, quand ils ont besoin de résidence des données, ou quand ils doivent intégrer des systèmes on-prem que Cloud ne peut pas atteindre.

Pour aller plus loin

Si vous voulez de l'aide pour déployer ce setup pour votre équipe sans dérouler le YAML vous-même, voir notre page services d'automatisation de workflow. Nous déployons exactement cette architecture en mission au périmètre fixe pour les clients européens, régulièrement.

Si vous hésitez encore entre n8n, Zapier et Make, le comparatif n8n vs Zapier vs Make est l'article précédent de cette série et couvre les arbitrages en profondeur.