Installer Redis sur un VPS : cache et files d'attente pour vos apps

Redis est un store clé-valeur en mémoire conçu pour répondre avec une très faible latence. Il sert notamment de cache applicatif, de store de sessions, de mécanisme pub/sub et de broker pour des files de tâches utilisées par Celery, BullMQ, Sidekiq ou le mode queue de n8n.

Sa rapidité vient du stockage en RAM. Cette caractéristique implique une contrepartie : sans persistance, les données disparaissent lors d’un redémarrage. Redis propose donc des snapshots RDB et un journal AOF. Leur configuration dépend du rôle de l’instance et de la quantité de données qu’une application peut accepter de perdre.

Prérequis

Pour ce déploiement, il faut disposer :

• d’un VPS Linux avec Docker et le plugin Docker Compose (voir installer Docker sur un VPS) ;
• d’au moins 1 Go de RAM pour un petit cache, davantage selon les données et les files ;
• d’un accès SSH avec un compte autorisé à gérer Docker ;
• d’un pare-feu actif ;
• d’une application locale, conteneurisée ou reliée au VPS par un réseau privé.

Les VPS TalCloud sont hébergés en France avec stockage NVMe, protection Anti-DDoS Netrix et support humain. Cette localisation facilite également les architectures soumises au RGPD, sous réserve de configurer correctement les applications, les sauvegardes et les durées de conservation.

Vérifiez l’installation :

docker --version
docker compose version

Déployer Redis avec Docker Compose

Créez un répertoire dédié et placez-y un fichier compose.yaml :

services:
  redis:
    image: redis:7-alpine
    container_name: redis
    restart: unless-stopped
    command:
      - redis-server
      - --requirepass
      - ${REDIS_PASSWORD}
      - --protected-mode
      - "yes"
      - --appendonly
      - "yes"
    ports:
      - "127.0.0.1:6379:6379"
    volumes:
      - redis_data:/data

volumes:
  redis_data:

Ajoutez le secret dans un fichier .env, placé dans le même répertoire :

REDIS_PASSWORD=remplacez_par_un_secret_long_et_aleatoire

Un secret peut être généré avec :

openssl rand -base64 48

Protégez le fichier puis démarrez Redis :

chmod 600 .env
docker compose up -d
docker compose ps
docker compose logs redis

Le port 6379 est lié exclusivement à 127.0.0.1. Il reste accessible depuis le VPS, mais pas directement depuis Internet. Le volume redis_data conserve les fichiers placés dans /data lorsque le conteneur est remplacé.

L’option --appendonly yes active AOF. Redis conserve alors un journal des écritures en plus de ses snapshots RDB. Pour un simple cache reconstructible, RDB seul peut suffire. Pour des sessions ou des tâches importantes, AOF réduit généralement le risque de perte après un incident.

Sécuriser Redis impérativement

Une instance Redis sans mot de passe et exposée publiquement conduit à une compromission quasi certaine. Les scans automatisés recherchent en permanence les ports Redis ouverts afin d’effacer les données, modifier la configuration ou installer des cryptominers.

Les règles minimales sont les suivantes :

• imposer un mot de passe avec requirepass ;
• ne jamais publier le port 6379 sur toutes les interfaces ;
• conserver protected-mode yes ;
• filtrer le port avec le pare-feu du VPS ;
• ne pas intégrer le secret dans Git ;
• utiliser un VPN, un tunnel SSH ou un réseau privé pour tout accès distant.

La déclaration suivante serait dangereuse :

ports:
  - "6379:6379"

Elle publie potentiellement Redis sur l’adresse publique du serveur. La liaison correcte est :

ports:
  - "127.0.0.1:6379:6379"

Si toutes les applications partagent le même réseau Docker Compose, la section ports peut même être supprimée. Les conteneurs accèdent alors à Redis avec le nom de service redis.

Pour des permissions plus fines, Redis 7 prend également en charge les ACL. Elles permettent de créer des utilisateurs limités à certaines commandes ou clés. Cette approche est préférable lorsque plusieurs applications partagent une instance.

Se connecter avec redis-cli

Ouvrez un client dans le conteneur :

docker compose exec redis redis-cli

Authentifiez-vous sans placer le secret dans l’historique du terminal :

AUTH votre_mot_de_passe
PING

Redis doit répondre :

OK
PONG

Pour une application exécutée directement sur le VPS, la chaîne de connexion est :

redis://:motdepasse@127.0.0.1:6379/0

Depuis un conteneur présent sur le même réseau Docker, utilisez plutôt :

redis://:motdepasse@redis:6379/0

Le nombre final sélectionne une base logique. Cette séparation reste légère et ne remplace pas une isolation réelle. Pour séparer fortement un cache, des sessions et des files critiques, utilisez plusieurs instances Redis.

Mettre en place un cache applicatif

Un cache Redis doit toujours utiliser une expiration lorsque les données peuvent être recalculées :

SET fiche:produit:42 '{"nom":"Serveur VPS"}' EX 300
GET fiche:produit:42
TTL fiche:produit:42

La clé expire ici après 300 secondes. Les TTL évitent l’accumulation permanente de données obsolètes et simplifient l’invalidation.

Adoptez des noms de clés structurés :

cache:produit:42
cache:api:utilisateur:781
cache:recherche:empreinte_de_la_requete

Prévoyez aussi le comportement en cas d’indisponibilité. Une panne du cache ne devrait généralement pas rendre toute l’application inutilisable. L’application peut interroger sa base principale, quitte à répondre plus lentement.

Stocker les sessions

Redis convient bien aux sessions web partagées entre plusieurs instances d’une application. Une session doit avoir une expiration alignée sur sa durée de validité :

SET session:8f32a1 '{"userId":781,"role":"admin"}' EX 3600

Ne stockez pas de mot de passe, de jeton en clair ou de donnée personnelle inutile. Le RGPD impose notamment une finalité définie, une durée de conservation maîtrisée et des mesures de sécurité adaptées.

Pour les sessions, une politique d’éviction agressive peut provoquer des déconnexions imprévues. Il est donc prudent de séparer l’instance de sessions du cache applicatif ou de dimensionner sa mémoire avec une marge suffisante.

Utiliser Redis comme broker de files

Celery peut employer Redis comme broker et, si nécessaire, comme backend de résultats :

broker_url = redis://:motdepasse@redis:6379/0
result_backend = redis://:motdepasse@redis:6379/1

BullMQ reçoit une configuration de connexion similaire :

const connection = {
  host: "redis",
  port: 6379,
  password: process.env.REDIS_PASSWORD
};

Sidekiq accepte une URL Redis :

redis://:motdepasse@redis:6379/0

Pour n8n en mode queue, les variables essentielles ressemblent à ceci :

EXECUTIONS_MODE=queue
QUEUE_BULL_REDIS_HOST=redis
QUEUE_BULL_REDIS_PORT=6379
QUEUE_BULL_REDIS_PASSWORD=motdepasse
QUEUE_BULL_REDIS_DB=0

Dans tous ces cas, surveillez les tâches en attente, les échecs et la mémoire. Redis transporte ou conserve l’état de la file, mais le traitement dépend toujours de workers correctement configurés. Pour des tâches critiques, testez également les reprises après redémarrage et l’idempotence des jobs.

Choisir entre RDB et AOF

RDB crée des snapshots périodiques. Cette méthode produit des fichiers compacts et permet des restaurations rapides, mais les écritures effectuées depuis le dernier snapshot peuvent être perdues.

AOF journalise les commandes d’écriture. Avec la synchronisation habituelle toutes les secondes, la perte potentielle est plus faible, au prix de davantage d’écritures disque et de fichiers plus volumineux.

En pratique :

• cache reconstructible : RDB seul ou aucune persistance ;
• sessions : RDB fréquent ou AOF selon la tolérance aux déconnexions ;
• files de tâches : AOF recommandé, avec tests de reprise ;
• données irremplaçables : Redis ne doit pas être l’unique stockage durable.

Le stockage NVMe réduit la latence des écritures AOF et accélère les restaurations, mais il ne remplace ni la sauvegarde ni la réplication.

Limiter la mémoire et configurer l’éviction

Redis doit disposer d’une limite explicite afin de ne pas consommer toute la RAM du VPS. Pour une instance exclusivement dédiée au cache, ajoutez à la commande Compose :

      - --maxmemory
      - 1gb
      - --maxmemory-policy
      - allkeys-lru

allkeys-lru supprime en priorité des clés récemment peu utilisées lorsque la limite est atteinte. Cette politique convient à un cache, mais pas à une file de tâches ou à un store de sessions critique : Redis pourrait supprimer des données encore nécessaires. Pour ces usages, préférez une instance séparée, correctement dimensionnée, avec noeviction.

Sauvegarder et restaurer

Le fichier RDB est stocké dans /data/dump.rdb. Pour déclencher un snapshot :

docker compose exec redis redis-cli

Puis, dans le client :

AUTH votre_mot_de_passe
BGSAVE
LASTSAVE

Après confirmation de la fin du snapshot, copiez-le :

mkdir -p backups
docker compose cp redis:/data/dump.rdb ./backups/dump.rdb

Si AOF est activé, sauvegardez le volume complet ou utilisez un mécanisme de snapshot cohérent. Copier uniquement dump.rdb peut omettre les écritures plus récentes présentes dans les fichiers AOF.

Conservez au moins une copie hors du VPS, chiffrez les sauvegardes contenant des données sensibles et testez régulièrement une restauration. Notre guide sur la stratégie de sauvegarde d’un serveur complète cette approche. Une sauvegarde non testée reste une hypothèse.

Mettre à jour et superviser Redis

Consultez régulièrement les statistiques :

docker compose exec redis redis-cli

Puis :

AUTH votre_mot_de_passe
INFO
INFO memory
INFO persistence
INFO stats
DBSIZE

Surveillez particulièrement used_memory, maxmemory, les évictions, les connexions refusées, l’état AOF, la date du dernier snapshot et le nombre de clés expirées.

Avant une mise à jour, sauvegardez les données et lisez les changements de compatibilité. Testez la nouvelle image hors production, puis appliquez-la :

docker compose pull redis
docker compose up -d redis
docker compose logs redis

Le tag redis:7-alpine suit Redis 7 et peut évoluer. Pour une production reproductible, figez une version précise ou un digest, puis planifiez volontairement les mises à niveau. Terminez chaque opération par un test PING, une vérification de l’application et un contrôle des workers de files.