n8n : l’automatisation sans code
La première alerte Grafana a atterri dans Telegram sans qu’aucun email ne soit configuré, sans dashboard ouvert — juste un message qui arrivait au bon endroit. C’est ce genre d’automatisation, connecter deux services qui n’étaient pas censés se parler directement, que n8n rend triviale dans le homelab.
n8n est un outil d’automatisation de workflows open-source, similaire à Zapier ou Make, mais auto-hébergeable. Il permet de connecter des services entre eux via une interface visuelle — déclencher une action quand un événement se produit, transformer des données, envoyer des notifications.
Dans le homelab, n8n orchestre des tâches qui seraient autrement des scripts cron dispersés :
- Notifications Telegram en cas d’alerte Grafana
- Backup automatique de configurations vers Gitea
- Rapport hebdomadaire sur l’état du cluster
- Webhooks entre services internes
Déploiement
Ce déploiement utilise PostgreSQL comme base de données et Redis pour la file d’exécution, avec un mode queue : 1 processus principal (n8n-main) + 2 workers. Ce setup permet aux workers de traiter les exécutions en parallèle sans bloquer l’interface.
# Deployment n8n-main
containers:
- name: n8n
image: n8nio/n8n:1.123.37
env:
- name: EXECUTIONS_MODE
value: queue
- name: QUEUE_BULL_REDIS_HOST
value: redis.n8n.svc.cluster.local
- name: DB_TYPE
value: postgresdb
- name: DB_POSTGRESDB_HOST
value: postgres.n8n.svc.cluster.local
- name: DB_POSTGRESDB_DATABASE
value: n8n
- name: DB_POSTGRESDB_USER
value: n8n
- name: DB_POSTGRESDB_PASSWORD
valueFrom:
secretKeyRef:
name: n8n-credentials
key: DB_PASSWORD
- name: N8N_ENCRYPTION_KEY
valueFrom:
secretKeyRef:
name: n8n-credentials
key: N8N_ENCRYPTION_KEY
- name: WEBHOOK_URL
value: https://n8n.olig-homelab-2025.win/
volumeMounts:
- name: data
mountPath: /home/node/.n8n
Mode queue : EXECUTIONS_MODE=queue + Redis découple l’interface de l’exécution des workflows. Les workers (pods séparés) consomment la queue Redis indépendamment du processus principal.
EXECUTIONS_MODE=queue : n8n-main dépose, les workers consomment en parallèle —
un workflow lourd n'a plus aucun impact sur l'interface. Les workers se scalent horizontalement,
n8n-main reste en strategy: Recreate (instance unique).
WEBHOOK_URL doit pointer vers l’URL publique du service — n8n l’utilise pour construire les URLs des webhooks exposés aux services externes.
Workflows typiques
Alerting Grafana → Telegram : Grafana envoie une alerte webhook à n8n. n8n formate le message et l’envoie via le bot Telegram. Plus lisible que les notifications email brutes de Grafana.
Health check quotidien : un workflow planifié (Cron node) interroge l’état des nœuds via l’API Kubernetes, formate un rapport en markdown, et envoie un message Telegram chaque matin.
Mirroring automatique (archi pré-migration, cf. mise à jour sur Self-Hosted Git Forge with Gitea) : ce workflow déclenchait une synchronisation du miroir Gitea dès qu’un dépôt GitHub était mis à jour. Il appartient à l’ancienne architecture où GitHub restait la source de vérité.
Leçons apprises
Mode queue vs single : le mode queue (PostgreSQL + Redis + workers séparés) est recommandé dès que l’on veut des exécutions parallèles fiables. En mode single, un workflow lourd bloque l’interface. En mode queue, les workers traitent les exécutions en arrière-plan.
strategy: Recreate sur le processus principal : n8n-main ne doit avoir qu’une seule instance active pour éviter les conflits. Les workers peuvent être scalés horizontalement sans restriction.
Exporter les workflows : n8n permet d’exporter les workflows en JSON. Versionner ces exports dans Git offre une sauvegarde et permet de reconstruire les automations après une réinstallation.
Secrets dans n8n : les credentials (tokens API, mots de passe) configurés dans n8n sont stockés chiffrés dans PostgreSQL. N8N_ENCRYPTION_KEY doit être stable — la changer invalide tous les credentials stockés. La stocker dans un SealedSecret et ne jamais la régénérer.