Alojar Redis en un VPS: la guía completa

Por qué autoalojar Redis en un VPS

Los beneficios concretos de un Redis autoalojado

• Latencia por debajo del milisegundo si Redis se ejecuta en el mismo VPS o en la misma red privada que su aplicación.
• Control de maxmemory y de la política de expulsión según su uso como caché o como cola de trabajos.
• Persistencia a elegir: RDB (snapshots), AOF (journal), o ambas para la durabilidad.
• Coste de RAM sin sobrefacturación: paga la tarifa del VPS, no el GB de memoria premium.
• Módulos libres: RediSearch, RedisJSON, RedisBloom según sus necesidades.
• Ningún tope arbitrario en el número de conexiones de clientes simultáneas.

Requisitos de hardware y software

Desplegar Redis con Docker en producción

1. 01

   Preparar el host

   Instale Docker, después ajuste vm.overcommit_memory=1 mediante sysctl para fiabilizar los snapshots, y desactive las Transparent Huge Pages. Cierre el puerto 6379 hacia el exterior: un Redis expuesto sin contraseña es un objetivo clásico de los criptomineros.

   echo 'vm.overcommit_memory = 1' >> /etc/sysctl.conf
   sysctl -p
   echo never > /sys/kernel/mm/transparent_hugepage/enabled

2. 02

   Escribir el docker-compose.yml

   Declare un servicio redis:7-alpine con un comando personalizado que apunte a un redis.conf montado en solo lectura. Active requirepass, defina maxmemory y maxmemory-policy, y monte un volumen para /data si desea la persistencia.

   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

   Configurar la seguridad

   En redis.conf, la seguridad descansa sobre varias capas complementarias. La primera es el binding de red: bind 127.0.0.1 o su IP de red privada — nunca escuche en 0.0.0.0 sin protección adicional. La segunda es la autenticación: requirepass SU_CONTRASEÑA_FUERTE para Redis 6 y anteriores; para Redis 7, prefiera las ACL que permiten crear usuarios con permisos granulares:

   bind 127.0.0.1
   requirepass SU_CONTRASEÑA_FUERTE
   aclfile /etc/redis/users.acl
   rename-command FLUSHALL ""
   rename-command CONFIG ""
   rename-command DEBUG ""

   El archivo users.acl puede declarar:

   user app_user on >CONTRASEÑA ~* +@read +@write -@dangerous
   user default off

   Para acceso remoto cifrado, active el TLS nativo de Redis (disponible desde Redis 6):

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

4. 04

   Elegir la estrategia de persistencia

   Redis ofrece dos mecanismos de persistencia, combinables.

   RDB (snapshot): Redis escribe una instantánea del dataset en disco a intervalos configurables. Rápido en el reinicio, pero pierde los datos escritos desde el último snapshot en caso de fallo.

   save 900 1
   save 300 10
   save 60 10000

   AOF (Append-Only File): cada comando de escritura se registra. Más seguro, algo más lento. appendfsync everysec es el buen equilibrio: como mucho 1 segundo de datos perdidos.

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

   Combinando RDB + AOF: al reiniciar, Redis usa el AOF (más completo), mientras que RDB acelera las copias de seguridad completas periódicas. Es la estrategia recomendada para brokers de trabajos críticos.

   Para una caché pura donde la pérdida de datos es aceptable, desactive la persistencia: save "" y appendonly no — gana rendimiento y espacio en disco.

5. 05

   Conectar su aplicación

   Lance con docker compose up -d y pruebe con docker compose exec redis redis-cli -a SU_PASS ping. Apunte su aplicación hacia la red Docker interna en lugar de hacia una IP pública, por latencia y por seguridad.

   docker compose exec redis redis-cli -a SU_PASS ping
   # PONG
   docker compose exec redis redis-cli -a SU_PASS CONFIG GET maxmemory

6. 06

   Vigilar la memoria

   Vigile used_memory y evicted_keys mediante redis-cli INFO. Si las expulsiones aumentan, incremente la RAM o afine la política. Configure una alerta cuando el uso de memoria supere el 80% de maxmemory.

   redis-cli -a SU_PASS INFO memory | grep -E 'used_memory_human|maxmemory_human|mem_fragmentation_ratio'
   redis-cli -a SU_PASS INFO stats | grep -E 'evicted_keys|keyspace_hits|keyspace_misses'

7. 07

   Conectarse por primera vez

   Abra la URL: RedisInsight se muestra directamente, SIN ninguna solicitud de credenciales (solo acepta las condiciones de uso en la primera pantalla), y su base Redis local ya está accesible en lectura/escritura. No asocie un dominio público a esta interfaz sin protección previa.

Resolución de errores: los más frecuentes

• MISCONF Redis is configured to save RDB snapshots, but it's currently unable to persist on disk — Redis intenta un snapshot pero el fork falla. Causa: vm.overcommit_memory está en 0 en el host. Solución: sysctl vm.overcommit_memory=1 (permanente en /etc/sysctl.conf). Si usa Docker, este parámetro debe establecerse en el host Docker, no dentro del contenedor.
• ERR max number of clients reached — El número de conexiones simultáneas supera maxclients (por defecto: 10.000). Causas frecuentes: pool de conexiones mal configurado en la aplicación (Sidekiq, Laravel Horizon, etc.) o conexiones no cerradas. Solución: aumente maxclients en redis.conf y verifique la configuración del pool en el lado de la app. El comando redis-cli CLIENT LIST lista las conexiones activas.
• El OOM Killer mata el proceso Redis — El kernel Linux mata Redis por falta de memoria libre. Causa: maxmemory no definido o demasiado generoso, combinado con la copia en escritura del fork RDB. Solución: fije maxmemory al 60-70% de la RAM disponible, elija una política de expulsión (maxmemory-policy allkeys-lru para caché, noeviction para broker), y planifique 2× el dataset para el fork RDB. Monitorice /var/log/syslog para mensajes Out of memory: Kill process.
• Could not create server TCP listening socket 0.0.0.0:6379: bind: Address already in use — Otro proceso ocupa el puerto 6379. Identifíquelo con ss -tlnp | grep 6379 y deténgalo, o cambie el puerto Redis en su configuración. En VPS con una instancia Redis instalada mediante apt, el servicio del sistema puede entrar en conflicto con su contenedor Docker.

Alta disponibilidad: Sentinel y Cluster

Actualizaciones y Valkey como alternativa