Héberger Redis sur un VPS : guide complet

Pourquoi auto-héberger Redis sur un VPS

Les bénéfices concrets d'un Redis auto-hébergé

• Latence sub-milliseconde si Redis tourne sur le même VPS ou le même réseau privé que votre app.
• Contrôle de maxmemory et de la politique d'éviction selon votre usage cache ou file de jobs.
• Persistance au choix : RDB (snapshots), AOF (journal), ou les deux pour la durabilité.
• Coût RAM sans surfacturation : vous payez le forfait VPS, pas le Go de mémoire premium.
• Modules libres : RediSearch, RedisJSON, RedisBloom selon vos besoins.
• Aucun plafond arbitraire sur le nombre de connexions clients simultanées.

Prérequis matériels et logiciels

Déployer Redis avec Docker en production

1. 01

   Préparer l'hôte

   Installez Docker, puis réglez vm.overcommit_memory=1 via sysctl pour fiabiliser les snapshots, et désactivez les Transparent Huge Pages. Fermez le port 6379 vers l'extérieur : un Redis exposé sans mot de passe est une cible classique de cryptomineurs.

   # Persistent via sysctl.conf
   echo 'vm.overcommit_memory = 1' >> /etc/sysctl.conf
   sysctl -p
   # Désactiver THP
   echo never > /sys/kernel/mm/transparent_hugepage/enabled

2. 02

   Écrire le docker-compose.yml

   Déclarez un service redis:7-alpine avec une commande personnalisée pointant vers un redis.conf monté en lecture seule. Activez requirepass, définissez maxmemory et maxmemory-policy, et montez un volume pour /data si vous voulez la persistance.

   services:
     redis:
       image: redis:7-alpine
       command: redis-server /etc/redis/redis.conf
       volumes:
         - ./redis.conf:/etc/redis/redis.conf:ro
         - redis_data:/data
       restart: unless-stopped
       ports:
         - "127.0.0.1:6379:6379"
   volumes:
     redis_data:

3. 03

   Configurer la sécurité

   Dans redis.conf, la sécurité repose sur plusieurs niveaux complémentaires. Le premier est le binding réseau : bind 127.0.0.1 ou votre IP de réseau privé — ne jamais écouter sur 0.0.0.0 sans protection supplémentaire. Le deuxième est l'authentification : requirepass VOTRE_MOT_DE_PASSE_FORT pour Redis 6 et antérieur ; pour Redis 7, préférez les ACL qui permettent de créer des utilisateurs avec des permissions granulaires :

   bind 127.0.0.1
   requirepass VOTRE_MOT_DE_PASSE_FORT
   # ACL Redis 7 : utilisateur lecture seule pour votre app
   aclfile /etc/redis/users.acl
   # Désactiver les commandes dangereuses
   rename-command FLUSHALL ""
   rename-command CONFIG ""
   rename-command DEBUG ""

   Le fichier users.acl peut déclarer :

   user app_user on >MOT_DE_PASSE ~* +@read +@write -@dangerous
   user default off

   Pour un accès distant chiffré, activez le TLS natif Redis (disponible depuis Redis 6) :

   tls-port 6380
   tls-cert-file /certs/redis.crt
   tls-key-file /certs/redis.key
   tls-ca-cert-file /certs/ca.crt

   Alternativement, un tunnel SSH ou un VPN suffit pour la plupart des cas sans complexité TLS.

4. 04

   Choisir la stratégie de persistance

   Redis propose deux mécanismes de persistance, combinables selon vos besoins.

   RDB (snapshot) : Redis écrit un instantané du dataset sur disque à intervalles configurables. Rapide au redémarrage, mais vous perdez les données écrites depuis le dernier snapshot en cas de crash.

   # Snapshot si 1 clé change en 900 s, 10 clés en 300 s, 10000 clés en 60 s
   save 900 1
   save 300 10
   save 60 10000

   AOF (Append-Only File) : chaque commande d'écriture est journalisée. Plus sûr, légèrement plus lent. appendfsync everysec est le bon compromis : au pire 1 seconde de données perdues.

   appendonly yes
   appendfsync everysec
   auto-aof-rewrite-percentage 100
   auto-aof-rewrite-min-size 64mb

   Combinaison RDB + AOF : au redémarrage, Redis utilise l'AOF (plus complet), et le RDB accélère les sauvegardes complètes périodiques. C'est la stratégie recommandée pour les brokers de jobs critiques.

   Pour un pur cache où la perte de données est acceptable, désactivez la persistance : save "" et appendonly no — vous gagnez en performance et en espace disque.

5. 05

   Connecter votre application

   Lancez avec docker compose up -d et testez avec docker compose exec redis redis-cli -a VOTRE_PASS ping. Faites pointer votre application vers le réseau Docker interne plutôt que vers une IP publique, pour la latence et la sécurité.

   # Test de connectivité
   docker compose exec redis redis-cli -a VOTRE_PASS ping
   # PONG
   
   # Vérifier la configuration active
   docker compose exec redis redis-cli -a VOTRE_PASS CONFIG GET maxmemory

   Pour les applications sur le même hôte Docker, utilisez le nom du service comme hôte (redis:6379) plutôt que localhost ou l'IP publique.

6. 06

   Surveiller la mémoire

   Surveillez used_memory et evicted_keys via redis-cli INFO. Si les évictions montent, augmentez la RAM ou affinez la politique. Configurez une alerte quand l'utilisation mémoire dépasse 80% de maxmemory.

   # Vue d'ensemble santé Redis
   redis-cli -a VOTRE_PASS INFO memory | grep -E 'used_memory_human|maxmemory_human|mem_fragmentation_ratio'
   redis-cli -a VOTRE_PASS INFO stats | grep -E 'evicted_keys|keyspace_hits|keyspace_misses'

   Un mem_fragmentation_ratio supérieur à 1,5 indique une fragmentation significative : un MEMORY PURGE ou un redémarrage progressif peut être utile.

7. 07

   Se connecter la première fois

   Ouvrez l'URL : RedisInsight s'affiche directement, SANS aucune demande d'identifiant (vous acceptez seulement les conditions d'utilisation au premier écran), et votre base Redis locale y est déjà accessible en lecture/écriture. N'attachez pas de domaine public à cette interface sans protection en amont.

Dépannage : les erreurs les plus fréquentes

• MISCONF Redis is configured to save RDB snapshots, but it's currently unable to persist on disk — Redis tente un snapshot mais le fork échoue. Cause : vm.overcommit_memory est à 0 sur l'hôte. Correction : sysctl vm.overcommit_memory=1 (permanent dans /etc/sysctl.conf). Si vous utilisez Docker, ce paramètre doit être posé sur l'hôte Docker, pas dans le conteneur.
• ERR max number of clients reached — Le nombre de connexions simultanées dépasse maxclients (défaut : 10 000). Causes fréquentes : pool de connexions mal configuré côté application (Sidekiq, Laravel Horizon, etc.) ou connexions non fermées. Correction : augmentez maxclients dans redis.conf et vérifiez la configuration du pool côté app. La commande redis-cli CLIENT LIST liste les connexions actives.
• OOM Killer tue le processus Redis — Le noyau Linux tue Redis faute de mémoire libre. Cause : maxmemory non défini ou trop généreux, couplé à la copie-sur-écriture du fork RDB. Correction : fixez maxmemory à 60-70 % de la RAM disponible, choisissez une politique d'éviction (maxmemory-policy allkeys-lru pour un cache, noeviction pour un broker), et prévoyez 2× le dataset pour le fork RDB. Surveillez /var/log/syslog pour les messages Out of memory: Kill process.
• Could not create server TCP listening socket 0.0.0.0:6379: bind: Address already in use — Un autre processus occupe le port 6379. Identifiez-le avec ss -tlnp | grep 6379 et arrêtez-le, ou changez le port Redis dans votre configuration. Sur les VPS avec une instance Redis installée via apt, le service système peut conflicuer avec votre conteneur Docker.

Haute disponibilité : Sentinel et Cluster

Mises à jour et alternative Valkey