Uptime Kuma sur le même serveur que n8n, n'est-ce pas absurde ?

Pour un PME en démarrage, oui c'est acceptable. Si le VPS tombe entièrement, vous perdez aussi le monitoring. Pour aller plus loin : déployez Uptime Kuma sur un second VPS Hostinger (KVM 1 à 6 €/mois) ou utilisez un service externe comme UptimeRobot (free tier 50 monitors). Le second VPS peut aussi héberger d'autres outils en parallèle (Vaultwarden, NextCloud personnel, etc.) et amortir son coût.

Faut-il vraiment lire les release notes de chaque version n8n ?

Pour les versions mineures (2.18.5 → 2.18.6) : juste le titre, généralement des bugfixes. Pour les versions majeures (2.x → 3.x si ça arrive) ou les versions plus espacées (2.18 → 2.20) : oui, parcourir au moins les sections 'Breaking changes' et 'Migration guide'. Cinq minutes vous évitent des heures de debug post-update.

Mes workflows tombent parfois en erreur avec 'execution lost', c'est quoi ?

C'est typique d'un manque de RAM : le worker n8n a été tué par l'OOM killer Linux car le serveur manquait de mémoire. Diagnostic : 'docker stats' pour voir la RAM consommée en temps réel, 'dmesg | grep -i kill' pour voir l'historique des kills. Solutions : (1) auto-prune plus agressif des executions (MAX_AGE=72h), (2) optimiser les workflows lourds (éviter de manipuler de gros JSON dans le Code node), (3) upgrader vers KVM 2 (8 Go RAM).

Comment savoir si je dois passer en queue mode ?

Trois signaux concrets : (1) votre éditeur n8n devient lent quand des workflows tournent (lag dans l'UI), (2) vous voyez des executions 'lost' fréquentes, (3) plusieurs personnes ne peuvent pas éditer simultanément sans gêne. Si vous cochez deux de ces trois, c'est le moment. Sinon restez en mode regular, c'est plus simple à maintenir.

Que faire si n8n refuse de redémarrer après un docker compose pull ?

Diagnostic immédiat : 'docker compose logs n8n --tail=200'. Causes courantes : (1) migration DB échouée (souvent à cause d'une transaction PostgreSQL bloquée d'avant), (2) variable d'env critique manquante dans la nouvelle version, (3) image corrompue (rare). Premier réflexe : revert au tag précédent dans docker-compose.yml, puis redémarrer. Si le revert ne fonctionne pas, restaurer depuis le backup d'avant-update.

Chapitre 7 : Monitoring et maintenance

Le minimum vital : Uptime Kuma + /healthz.

Vous n'avez pas besoin d'une stack Grafana + Prometheus + Loki + Tempo + AlertManager pour monitorer un n8n PME. C'est de la sur-ingénierie qui coûte plus de temps à maintenir que le bénéfice qu'elle apporte. Pour 95% des cas, deux outils suffisent :

Uptime Kuma : monitoring externe de disponibilité (gratuit, self-hosted, interface élégante)
L'endpoint /healthz de n8n : retourne HTTP 200 si tout va bien, à pinger toutes les minutes

En complément, deux outils optionnels mais utiles :

Netdata : métriques système temps réel (CPU, RAM, disque, réseau) pour diagnostiquer les pics
Un workflow n8n d'auto-monitoring : c'est-à-dire utiliser n8n pour surveiller n8n (méta mais efficace)

Installer Uptime Kuma sur le même VPS.

Uptime Kuma tourne en Docker, ajoutez-le à votre stack :

nano /opt/uptime-kuma/docker-compose.yml

services:
  uptime-kuma:
    image: louislam/uptime-kuma:1
    restart: always
    ports:
      - "127.0.0.1:3001:3001"
    volumes:
      - uptime_data:/app/data
    environment:
      - TZ=Europe/Paris

volumes:
  uptime_data:

cd /opt/uptime-kuma
mkdir -p uptime_data
docker compose up -d

Ajoutez un sous-domaine et configurez Caddy pour exposer Uptime Kuma en HTTPS :

sudo nano /etc/caddy/Caddyfile

# Ajouter en plus du bloc n8n existant :
status.votreboite.fr {
    reverse_proxy 127.0.0.1:3001
}

sudo systemctl reload caddy

Créez l'enregistrement DNS A pour status.votreboite.fr, puis accédez à l'URL. Uptime Kuma vous demande de créer un compte admin au premier login.

Configurer les checks dans Uptime Kuma.

Ajoutez 3 monitors essentiels :

Monitor 1 : Healthcheck n8n.

Type : HTTP(s)
Name : n8n - healthz
URL : https://n8n.votreboite.fr/healthz
Heartbeat Interval : 60 seconds
Retries : 3
Notifications : ajoutez Telegram, Slack, Email, Discord, ou webhook custom

Monitor 2 : Page d'éditeur n8n.

Type : HTTP(s)
URL : https://n8n.votreboite.fr/
Accept Status Codes : 200-302 (n8n redirige vers la page de login)
Vérifie qu'au-delà de l'API, l'éditeur web est accessible

Monitor 3 : Certificat SSL.

Type : HTTP(s)
Notification on certificate expiration : 7 days
Si Caddy oublie de renouveler, vous êtes prévenu une semaine avant

Les métriques Prometheus n8n (optionnel).

Si vous voulez aller plus loin, n8n expose des métriques Prometheus. Activez-les en ajoutant à votre /opt/n8n/.env :

N8N_METRICS=true
N8N_METRICS_INCLUDE_DEFAULT_METRICS=true
N8N_METRICS_INCLUDE_API_ENDPOINTS=true
N8N_METRICS_INCLUDE_CACHE_METRICS=true

Redémarrez n8n :

cd /opt/n8n && docker compose restart n8n

L'endpoint /metrics retourne maintenant le format Prometheus avec : nombre d'exécutions par statut, durée moyenne par workflow, requests HTTP par endpoint, etc. À combiner avec Prometheus + Grafana si vous voulez un dashboard visuel.

Pour une PME : ne le faites pas avant d'en avoir un vrai besoin. Uptime Kuma + /healthz sont suffisants pour 95% des situations.

Mises à jour mensuelles : la procédure éprouvée.

Cadence recommandée : mise à jour mensuelle de n8n et de Postgres, mises à jour Ubuntu via unattended-upgrades automatique (configuré au chapitre 2).

Procédure officielle, à exécuter à un moment où n8n n'est pas critique (typiquement le dimanche soir 22h) :

# 1. Backup IMMEDIAT (en plus du backup quotidien)
sudo /usr/local/bin/n8n-backup.sh

# 2. Verifier la version actuelle
cd /opt/n8n
docker compose images n8n

# 3. Verifier la nouvelle version disponible sur :
#    https://github.com/n8n-io/n8n/releases
#    Lire les release notes pour voir si breaking changes

# 4. Mettre a jour le tag dans docker-compose.yml
nano docker-compose.yml
# Remplacer : image: docker.n8n.io/n8nio/n8n:2.18.5
# Par :     : image: docker.n8n.io/n8nio/n8n:2.19.0  (par exemple)

# 5. Pull et restart
docker compose pull n8n
docker compose up -d n8n

# 6. Verifier les logs (migrations DB automatiques)
docker compose logs n8n --tail=100

# 7. Test fonctionnel : se connecter, executer un workflow simple

# 8. Si KO : rollback
nano docker-compose.yml  # remettre l'ancien tag
docker compose pull n8n
docker compose up -d n8n
# Si la migration DB est passée, restaurer aussi le pg_dump du backup pre-update

Updates de PostgreSQL : prudence.

PostgreSQL ne se met pas à jour aussi simplement que n8n. Une montée mineure (16.4 → 16.5) se fait juste avec docker compose pull postgres. Mais une montée majeure (16 → 17) nécessite une migration de schéma incompatible : pg_upgrade en mode hors-ligne.

Notre recommandation pragmatique pour une PME : restez sur PostgreSQL 16 pendant au moins 2 ans. Le support upstream de PostgreSQL 16 va jusqu'en novembre 2028. Vous aurez largement le temps de planifier la migration vers 17 ou 18 plus tard.

Quand passer en queue mode (workers).

Le mode "queue" sépare l'exécution des workflows du processus principal n8n. Architecture :

n8n main : sert l'éditeur, l'API, et reçoit les déclencheurs (webhooks, cron)
n8n workers : 1 à N processus qui consomment une queue Redis et exécutent les workflows
Redis : la file d'attente entre main et workers

Avantages : meilleure isolation (un workflow lourd ne bloque pas l'éditeur), scaling horizontal (ajouter des workers selon la charge), résistance aux crashs (un worker qui meurt n'arrête pas n8n).

Inconvénients : config plus complexe, besoin de Redis, RAM consommée plus importante (chaque worker = 200-500 Mo).

Critères pour basculer en queue mode :

Plus de 1000 exécutions par jour de workflows
Présence de workflows lourds (durée d'exécution >30s, gros JSON, traitement IA)
Plus de 10 workflows actifs simultanés
Plusieurs équipes utilisant n8n en parallèle (5+ utilisateurs en édition)

Si vous ne cochez aucun critère, restez en mode "regular" (défaut). C'est plus simple et largement suffisant.

docker-compose.yml en queue mode (extrait).

Si vous décidez de basculer, voici la structure (adaptée du repo officiel n8n-io/n8n-hosting) :

x-shared: &shared
  image: docker.n8n.io/n8nio/n8n:2.18.5
  restart: always
  environment:
    - DB_TYPE=postgresdb
    - DB_POSTGRESDB_HOST=postgres
    - DB_POSTGRESDB_USER=${POSTGRES_NON_ROOT_USER}
    - DB_POSTGRESDB_PASSWORD=${POSTGRES_NON_ROOT_PASSWORD}
    - DB_POSTGRESDB_DATABASE=${POSTGRES_DB}
    - EXECUTIONS_MODE=queue
    - QUEUE_BULL_REDIS_HOST=redis
    - QUEUE_HEALTH_CHECK_ACTIVE=true
    - N8N_ENCRYPTION_KEY=${N8N_ENCRYPTION_KEY}
    - GENERIC_TIMEZONE=Europe/Paris

services:
  postgres: # ... identique au compose simple

  redis:
    image: redis:6-alpine
    restart: always
    volumes:
      - redis_data:/data

  n8n:                    # main : editeur, API, webhooks, scheduler
    <<: *shared
    ports: ["127.0.0.1:5678:5678"]

  n8n-worker:             # worker : execute les workflows
    <<: *shared
    command: worker
    deploy:
      replicas: 2          # 2 workers pour debuter, scaler ensuite

volumes:
  db_storage:
  n8n_storage:
  redis_data:

Migration regular → queue : faire un backup, modifier le compose, restart. PostgreSQL est obligatoire en queue mode (SQLite n'est pas supporté).

Maintenance courante : les 30 minutes mensuelles.

Concrètement, voici ce que vous faites chaque mois sur un n8n auto-hébergé en bonne santé :

Tâche	Temps
Vérifier les notifications Uptime Kuma du mois	2 min
Lire les release notes n8n (GitHub)	5 min
Backup manuel + mise à jour n8n	15 min
Test fonctionnel post-update	5 min
Vérifier l'espace disque (df -h)	1 min
Vérifier le dernier backup offsite Scaleway	2 min

Total : 30 min/mois, soit 6h/an. Pour économiser ~500 €/an vs n8n cloud, le ratio est largement favorable.

Récapitulatif maintenance : votre routine.

✅ Uptime Kuma installé et configurable sur status.votreboite.fr
✅ 3 monitors actifs : healthz, éditeur, certificat SSL
✅ Notifications configurées (Telegram ou Slack)
✅ Cadence mensuelle de mise à jour n8n planifiée
✅ Procédure rollback connue et testée
✅ Critères de bascule en queue mode identifiés (en réserve si croissance)
✅ Routine 30 min/mois inscrite dans votre agenda

Plus qu'un chapitre. Le 8e est le grand final : on construit ensemble un workflow IA conforme AI Act 2026 sur votre nouvelle infrastructure auto-hébergée.

Monitoring, mises à jour et passage en queue mode.