n8n auto-hébergé conforme DSGVO 2026 : guide pas à pas avec Hetzner

L'auto-hébergement de n8n signifie que vous exploitez la plateforme open source d'automatisation de workflows n8n sur votre propre serveur — entièrement sous votre contrôle, dans un centre de données de l'UE, sans qu'aucune donnée de workflow ni aucun identifiant ne quitte jamais le serveur d'un tiers.

Pourquoi auto-héberger n8n ? DSGVO, coûts et maîtrise des données

Pour les entreprises françaises qui font transiter des données à caractère personnel par leurs automatisations — contacts clients, factures, données RH —, la question de l'hébergement n'est pas purement technique. C'est une question de conformité. n8n Cloud et les plateformes SaaS concurrentes telles que Zapier ou Make.com stockent les données d'exécution des workflows sur des serveurs situés hors de l'UE, ce qui impose, pour des données sensibles, un contrat de sous-traitance au titre de l'art. 28 du DSGVO et peut s'avérer problématique dans certains cas.

L'auto-hébergement résout entièrement ce problème : toutes les données de workflow, les identifiants et les journaux d'exécution restent sur votre serveur — dans le centre de données allemand de Hetzner Cloud, certifié ISO 27001 et conforme au DSGVO selon le droit allemand. Le catalogue BSI IT-Grundschutz, module OPS.1.1.7 (automatisation des processus d'exploitation) recommande explicitement d'exploiter les processus automatisés traitant des données à caractère personnel ou sensibles sous un plein contrôle organisationnel et d'instaurer des concepts d'habilitation distincts.

Le deuxième avantage est d'ordre économique : la n8n Community Edition est exempte de frais de licence (licence MIT). Vous ne payez que le serveur Hetzner — à partir de 5 EUR par mois pour un Hetzner CX22. De quoi exploiter jusqu'à 100 workflows actifs avec des centaines d'exécutions quotidiennes. À titre de comparaison, Zapier coûte 99 à 299 USD par mois pour un volume d'exécution équivalent.

La pleine maîtrise des données constitue le troisième aspect : vous décidez de la durée de conservation des données d'exécution, des collaborateurs autorisés à accéder aux identifiants, ainsi que de la stratégie de sauvegarde et de reprise. Conformément à l'art. 32 du DSGVO (sécurité du traitement), ces mesures techniques et organisationnelles sont de toute façon obligatoires — l'auto-hébergement en facilite la mise en œuvre et la justification.

Configuration matérielle : quel serveur Hetzner suffit ?

Pour la plupart des environnements de PME comptant jusqu'à 100 workflows actifs, un Hetzner CX22 (2 vCPU, 4 Go de RAM, 40 Go de SSD) est amplement suffisant. Ce type de serveur coûte 5 EUR par mois et encaisse sans peine plusieurs milliers d'exécutions de workflows par jour, sans dégradation des performances.

Les prérequis minimaux pour n8n avec une base PostgreSQL et une file Redis en mode Queue : 2 vCPU, 4 Go de RAM, 40 Go de SSD. Au-delà de 50 à 100 exécutions de workflows simultanées, mieux vaut passer à un Hetzner CX32 (4 vCPU, 8 Go de RAM, 80 Go de SSD, env. 10 EUR/mois). Une instance Redis pour le mode Queue occupe environ 50 à 100 Mo de RAM, PostgreSQL généralement 300 à 500 Mo.

Recommandation pour l'emplacement du serveur : nbg1 (Nuremberg) ou fsn1 (Falkenstein) — ces deux centres de données sont situés en Allemagne, certifiés ISO 27001 et relèvent exclusivement du droit allemand et européen. Lors de la mise en service, évitez les emplacements américains tels que les centres de données Hetzner d'Ashburn (us-east), même s'ils paraissent plus avantageux : ils relèvent du droit américain et du Cloud Act.

• Hetzner CX22 (2 vCPU / 4 Go / 40 Go) : 5 EUR/mois — pour jusqu'à 100 workflows, env. 5 000 exécutions/jour
• Hetzner CX32 (4 vCPU / 8 Go / 80 Go) : 10 EUR/mois — pour jusqu'à 300 workflows, env. 50 000 exécutions/jour
• Hetzner CCX23 (4 vCPU dédiés / 16 Go) : 22 EUR/mois — pour des installations critiques à très haut volume

Configuration Docker Compose : l'installation complète

La documentation officielle de n8n, à l'adresse docs.n8n.io/hosting/installation/server-setups/docker-compose/, met à disposition un modèle complet de `docker-compose.yml`. L'installation prête pour la production en PME regroupe quatre services : n8n (moteur de workflows), postgres (stockage persistant des données), redis (file d'attente pour les exécutions parallèles) et caddy (reverse proxy avec TLS automatique).

L'élément le plus critique de la configuration est la N8N_ENCRYPTION_KEY : cette clé de 32 octets chiffre, dans la base PostgreSQL, tous les identifiants enregistrés dans n8n (clés d'API, jetons OAuth, mots de passe). Elle doit être générée avant le premier démarrage (`openssl rand -hex 32`), placée en lieu sûr dans le fichier `.env` et sauvegardée séparément — idéalement dans un gestionnaire de mots de passe comme Bitwarden ou 1Password. Sans cette clé, les identifiants enregistrés deviennent inutilisables après un changement de serveur.

Pour la configuration de protection des données au titre du DSGVO, deux variables d'environnement n8n sont particulièrement pertinentes : `N8N_EXECUTIONS_DATA_PRUNE=true` limite la conservation des données d'exécution des workflows, et `N8N_EXECUTIONS_DATA_MAX_AGE=720` fixe la durée de conservation maximale à 30 jours. Pour les workflows traitant des données particulièrement sensibles (données de santé, données financières), il est recommandé d'ajouter `N8N_EXECUTIONS_DATA_SAVE_ON_SUCCESS=none` afin de ne pas persister les exécutions réussies.

Exemple de configuration du fichier `.env` (champs obligatoires) :

N8N_ENCRYPTION_KEY=<chaîne-hex-de-32-octets> | DB_TYPE=postgresdb | DB_POSTGRESDB_HOST=postgres | DB_POSTGRESDB_DATABASE=n8n | DB_POSTGRESDB_USER=n8n | DB_POSTGRESDB_PASSWORD=<mot-de-passe-robuste> | QUEUE_BULL_REDIS_HOST=redis | N8N_HOST=n8n.votre-domaine.fr | N8N_PROTOCOL=https | N8N_EXECUTIONS_DATA_PRUNE=true | N8N_EXECUTIONS_DATA_MAX_AGE=720

Toutes les images Docker devraient être épinglées sur des tags de version explicites (p. ex. `n8nio/n8n:1.85.0` plutôt que `n8nio/n8n:latest`), afin d'éviter des ruptures de compatibilité inattendues dues à des mises à jour automatiques. Une fenêtre de mise à jour mensuelle, manuelle et précédée d'une vérification des sauvegardes constitue la stratégie de maintenance recommandée.

TLS, sauvegardes, supervision — les trois volets obligatoires

TLS automatique via Caddy ou Traefik

Caddy est l'option la plus simple pour qui débute en auto-hébergement : un `Caddyfile` de deux lignes (`n8n.votre-domaine.fr { reverse_proxy n8n:5678 }`) suffit pour un TLS automatique complet via Let's Encrypt. Caddy renouvelle les certificats automatiquement avant leur expiration. Traefik est l'alternative pour des installations plus complexes regroupant plusieurs services sur un même serveur — configurable exclusivement via des labels Docker sur le conteneur n8n. Les deux solutions sont gratuites, largement répandues et documentées dans la communauté n8n.

Sauvegardes PostgreSQL quotidiennes vers la Hetzner Storage Box

Les données les plus critiques d'une installation n8n sont la base PostgreSQL (définitions de workflows, historique d'exécution, identifiants) et le fichier `.env` contenant la clé de chiffrement. Un cron quotidien (`pg_dump | gzip | rclone copy`) sauvegarde la base vers la Hetzner Storage Box BX11 (1 To, 3,81 EUR/mois). Rétention : 7 sauvegardes quotidiennes, 4 hebdomadaires. Ne laissez jamais la clé de chiffrement uniquement sur le serveur — sauvegardez-la toujours séparément dans un gestionnaire de mots de passe.

Supervision via Uptime Kuma

Uptime Kuma est un service de supervision gratuit et auto-hébergé qui tourne dans un conteneur Docker sur le même serveur Hetzner. Contrôle HTTP de l'URL n8n toutes les 60 secondes, alerte par e-mail, Telegram ou Slack en cas de panne. Combiné au workflow d'erreur natif de n8n (message Slack en cas d'échec d'un workflow de production), il constitue une supervision complète sans coût SaaS supplémentaire.

Liste de contrôle conformité avant la mise en production

Avant que la première instance n8n traitant des données à caractère personnel ne passe en production, tous les points de cette liste devraient être satisfaits. Elle s'appuie sur les exigences de l'art. 32 du DSGVO (mesures techniques et organisationnelles) et sur les recommandations du BSI IT-Grundschutz OPS.1.1.7.

• Contrat de sous-traitance conclu avec Hetzner — au titre de l'art. 28 du DSGVO (gratuit, accessible via l'espace client Hetzner)
• Clé de chiffrement n8n stockée en lieu sûr — dans un gestionnaire de mots de passe (Bitwarden, 1Password), pas uniquement dans le fichier .env sur le serveur
• TLS actif et vérifié — le test SSL Labs (ssllabs.com/ssltest) donne au minimum la note A
• Restauration de sauvegarde testée — au moins une restauration effectuée manuellement, exhaustivité de la sauvegarde vérifiée
• Historique d'exécution limité — N8N_EXECUTIONS_DATA_PRUNE=true, durée de conservation fixée à 30 jours
• Formation des collaborateurs documentée — qui peut accéder à n8n et qui ne le peut pas ; gestion des identifiants encadrée
• Plan de reprise disponible — par écrit : que se passe-t-il en cas de panne du serveur ? Combien de temps dure la restauration ? Qui en est responsable ?
• Analyse d'impact relative à la protection des données examinée — pour les workflows traitant des données particulièrement sensibles (santé, finances, données des salariés), une AIPD au titre de l'art. 35 du DSGVO peut être requise