Connecter Redis à n8n : cache, compteurs et déduplication sans base de données

Un pipeline n8n qui vérifie chaque appel dans Postgres pour savoir s'il a déjà traité un item, ou qui compte des requêtes par minute avec une table dédiée, résout le problème — mais paie à chaque exécution le coût d'une connexion et d'une requête SQL pour une donnée qui n'a besoin de vivre que quelques secondes ou quelques minutes. Redis, base clé-valeur en mémoire, répond exactement à ce besoin : lecture et écriture en sous-milliseconde, expiration automatique des clés, et une poignée d'opérations qui couvrent le cache, les compteurs et la communication entre workflows. Ce guide détaille le node Redis de n8n, ses opérations réelles, et les trois cas d'usage où il remplace avantageusement un aller-retour vers votre base principale.

Se connecter : le credential Redis

Le credential Redis de n8n demande peu de paramètres : Host, Port (6379 par défaut), un Password optionnel, l'index de base logique (Database Number, 0 par défaut — Redis segmente une même instance en 16 bases numérotées) et une case SSL à cocher pour les services managés qui l'exigent (Upstash, Redis Cloud, la plupart des offres cloud).

En Docker local, comme pour les autres nodes de base de données de n8n, l'hôte à renseigner est le nom du service Docker (redis dans un docker-compose.yml type), jamais localhost qui désignerait le conteneur n8n lui-même. Si votre instance n8n tourne déjà en mode queue avec Redis pour distribuer les exécutions entre workers, vous pouvez réutiliser cette même instance Redis pour le node applicatif décrit ici — à condition de séparer les usages sur des index de base différents (par exemple 0 pour la queue interne de n8n, 1 pour votre cache applicatif) afin d'éviter toute collision de clés.

Les opérations du node Redis

Le node expose dix opérations, à choisir selon le besoin :

• Set — écrit une clé. Le paramètre Key Type propose Automatic, String, Hash, List ou Sets ; pour un objet structuré, l'option Value Is JSON stocke directement un objet en type Hash. L'option Expire avec un TTL en secondes rend l'écriture temporaire — c'est le paramètre central pour tout usage de cache.
• Get — lit une clé, avec les mêmes options de Key Type pour préciser le format attendu en lecture.
• Increment — incrémente atomiquement une clé numérique (et la crée à 0 si elle n'existe pas), avec les mêmes options Expire/TTL. C'est l'opération clé pour un compteur.
• Delete — supprime une clé.
• Keys — retourne les clés correspondant à un motif (pattern), avec une option pour récupérer directement leurs valeurs.
• Push / Pop — ajoute ou retire un élément d'une liste Redis, avec une option Tail pour choisir l'extrémité (pile ou file).
• List Length — renvoie la taille d'une liste.
• Publish — envoie un message sur un canal Redis, à destination de tout abonné (voir Redis Trigger plus bas).
• Info — renvoie les informations générales de l'instance Redis (mémoire utilisée, version, clients connectés) — utile pour un workflow de supervision.

L'atomicité d'Increment est ce qui distingue Redis d'un simple Get suivi d'un Set : deux exécutions concurrentes qui incrémentent la même clé au même instant ne s'écrasent jamais l'une l'autre, contrairement à un schéma lecture-puis-écriture en base relationnelle sans verrou explicite.

Cas d'usage 1 : cache court terme sans solliciter la base principale

Le cas le plus direct : éviter de rappeler une API tierce ou de refaire un calcul coûteux pour une donnée qui ne change pas d'une exécution à l'autre dans une fenêtre de quelques minutes — un taux de change, le résultat d'un enrichissement de lead, une réponse d'API météo. Le motif est toujours le même : Get sur la clé avant l'appel coûteux, un node IF qui saute l'appel si une valeur existe déjà, puis Set avec Expire activé après l'appel réel pour peupler le cache pour les prochaines exécutions.

Ce motif diffère du cache sémantique décrit dans notre guide sur la mise en cache Redis des réponses IA : là où le cache sémantique compare des questions proches mais pas identiques via des embeddings avant de taper Redis, le cache simple ici compare une clé exacte — un identifiant, un paramètre normalisé. Les deux se combinent bien : le cache exact absorbe les requêtes répétées à l'identique, le cache sémantique absorbe les reformulations.

Une étude de Privalov et Stupina (2024), publiée dans l'Indonesian Journal of Electrical Engineering and Computer Science (« Improving web-oriented information systems efficiency using Redis caching mechanisms », étude sur Google Scholar), mesure l'effet d'une couche de cache Redis ajoutée devant une base relationnelle sur une application web : le temps de récupération des données a chuté de 80,9 % et le temps de traitement des commandes de 72,3 % dans leurs tests. L'ordre de grandeur ne se transpose pas tel quel à un workflow n8n, mais la conclusion structurelle tient : dès qu'une lecture revient plusieurs fois avec les mêmes paramètres, intercepter ce trajet avec Redis coûte largement moins cher qu'y renvoyer systématiquement la base ou l'API.

Cas d'usage 2 : compteurs et rate limiting

Increment avec Expire construit un compteur à fenêtre glissante en une seule opération : une clé nommée par exemple ratelimit:{{ $json.userId }}:{{ $now.toFormat('yyyy-MM-dd-HH-mm') }} s'incrémente à chaque appel et expire automatiquement à la minute suivante, sans job de nettoyage à prévoir. Un node IF placé juste après compare la valeur retournée à votre seuil et bloque ou retarde l'exécution au-delà.

C'est un complément léger au cadencement décrit dans notre guide sur les rate limits des API OpenAI et Anthropic, qui repose sur Loop Over Items et Wait pour cadencer un traitement par lots que vous contrôlez de bout en bout. Le compteur Redis, lui, s'applique quand la contrainte à respecter n'est pas celle d'un fournisseur IA mais la vôtre — par exemple limiter le nombre d'actions qu'un utilisateur final peut déclencher par minute sur un workflow exposé en webhook, avant même d'atteindre le premier appel IA.

Cas d'usage 3 : déduplication légère

Pour bloquer le traitement d'un même événement reçu deux fois, le motif Redis tient en une opération : Set sur une clé dérivée de l'identifiant de l'événement, avec l'option Value Is JSON désactivée et un TTL couvrant la fenêtre de rejeu plausible (quelques heures suffisent pour la plupart des webhooks). Si la clé existe déjà, un Get préalable renvoie la valeur et le workflow s'arrête ; sinon le traitement continue.

Ce motif reste plus léger qu'une contrainte unique en base — mais aussi moins strict. Notre guide sur l'idempotence des webhooks n8n détaille pourquoi un enchaînement Get-puis-Set n'est pas atomique face à deux requêtes vraiment simultanées, et recommande une contrainte unique Postgres avec upsert pour les cas où un doublon a un coût réel (facturation, envoi d'un paiement). Réservez la déduplication Redis aux cas où un faux négatif occasionnel (un doublon qui passe malgré tout) est tolérable — une alerte Slack envoyée deux fois plutôt qu'une facture émise deux fois.

Redis Trigger : faire communiquer deux workflows sans webhook

Le nœud Publish a un pendant côté déclenchement : Redis Trigger démarre un workflow dès qu'un message arrive sur le canal auquel il est abonné. Le motif type — un workflow A traite un événement puis exécute Publish sur un canal evenement-traite, tandis qu'un workflow B, indépendant et démarré par un Redis Trigger abonné à ce même canal, réagit à son tour. Cela découple les deux workflows sans passer par un webhook interne à sécuriser ni par un Execute Sub-workflow qui les couplerait directement l'un à l'autre. C'est particulièrement utile pour notifier plusieurs workflows en parallèle depuis un seul événement : chacun s'abonne au canal qui l'intéresse, sans que le premier workflow ait besoin de connaître leur existence.

Managé ou auto-hébergé

Pour démarrer, un service Redis managé avec palier gratuit (Upstash, Redis Cloud) évite d'ajouter un service de plus à surveiller — la latence réseau supplémentaire reste négligeable face aux quelques millisecondes d'un appel Redis. Basculez vers une instance Redis auto-hébergée en conteneur à côté de n8n, comme décrit dans notre guide d'installation Docker, quand le volume d'opérations par seconde justifie d'éliminer cette latence réseau, ou quand une instance Redis tourne déjà pour le mode queue de votre instance — mutualiser l'infrastructure plutôt que d'en payer deux.

Pièges fréquents

• Oublier le TTL : sans option Expire activée sur Set ou Increment, une clé de cache censée être temporaire reste en mémoire indéfiniment — une fuite silencieuse qui grossit la facture d'un Redis managé jusqu'à ce que quelqu'un s'en aperçoive.
• Mélanger les usages sur le même index de base : queue mode de n8n et cache applicatif sur l'index 0 par défaut peuvent techniquement cohabiter, mais un pattern de clé mal choisi côté applicatif peut collisionner avec les clés internes de n8n ; séparez les index de base dès que possible.
• Traiter Redis comme une base durable : une instance Redis mal configurée (sans persistance AOF/RDB activée côté serveur) perd son contenu au redémarrage — parfait pour du cache, dangereux pour une donnée qu'on ne peut pas se permettre de reconstruire.
• Ignorer l'atomicité de Get-puis-Set : pour une déduplication stricte à fort volume concurrent, préférez une contrainte unique en base plutôt que ce motif, qui reste sujet à une fenêtre de course entre les deux appels Redis.

Pour aller plus loin

Le cadencement décrit dans le Pack Inbox IA (79 €) et la file d'attente du Pack Assistant RAG (119 €) s'appuient aujourd'hui sur des tables Supabase pour l'essentiel de leur journalisation — un choix délibéré pour la durabilité des données côté produit. Le node Redis présenté ici s'ajoute naturellement en complément dans vos propres workflows dès que la donnée à stocker est temporaire par nature : un cache d'API, un compteur de rate limit, un signal entre deux workflows. Si vous démarrez tout juste avec les nodes de base de données de n8n, notre guide du node Postgres reste le point de départ pour tout ce qui doit survivre au-delà de quelques minutes.