Guía completa para desplegar Redis con Docker: persistencia y autenticación por contraseña

Por fin tenía Redis corriendo en un contenedor. Probé varias APIs y la lectura/escritura funcionaba bien. Al día siguiente abrí el portátil para revisar el servicio: todos los datos habían desaparecido. Se me heló el corazón.

Quizá te ha pasado lo mismo: reinicias el contenedor de Docker y los datos de Redis parecen no haber existido nunca. Sesiones de usuario perdidas, carritos vacíos, caché desaparecida. Peor aún, no sabes por qué ocurre ni cómo solucionarlo.

La primera vez que me pasó también me asusté. Era un proyecto pequeño; en el entorno de pruebas los datos desaparecieron de repente. No afectaba a producción, pero esa sensación de impotencia no se olvida. Los contenedores son «temporales» por diseño: si los borras, los datos se van; si reinicias sin persistencia, ocurre lo mismo.

En este artículo te guío paso a paso para:

• Configurar persistencia RDB y AOF, para que Redis no pierda datos al reiniciar el contenedor
• Definir autenticación por contraseña, y evitar acceso no autorizado (hay empresas cuyo Redis sin contraseña fue comprometido para minar criptomonedas)
• Montar archivos de configuración, para un despliegue ordenado y mantenible
• Buenas prácticas de producción, incluyendo logs, healthcheck y optimización de rendimiento

Tanto si eres desarrollador backend, ingeniero de operaciones o recién llegado a Docker, si sigues este artículo podrás desplegar un contenedor Redis listo para producción.

¿Por qué un contenedor Redis pierde datos?

Una analogía: un contenedor Docker es como una habitación de hotel; al hacer checkout, lo que dejaste dentro se limpia. Lo mismo con el contenedor: es temporal; al eliminarlo, los datos desaparecen.

Redis guarda los datos por defecto en el sistema de archivos interno del contenedor. Cuando escribes datos, Redis los persiste en rutas como /data/dump.rdb o /data/appendonly.aof. El problema es que esas rutas están dentro del contenedor. Si el contenedor se borra o se recrea, esos datos se pierden.

Caso real: una startup desplegó Redis con Docker en pruebas sin persistencia. Tras reiniciar el servidor, todas las sesiones de usuario desaparecieron: login y carritos a cero. Era solo pruebas, pero el equipo entendió que en contenedores hay que pensar en persistencia.

Se estima que alrededor del 70 % de los casos de pérdida de datos en contenedores Redis se deben a no configurar almacenamiento persistente. En otras palabras, casi todos pisamos esta trampa alguna vez.

El papel del Docker Volume

El Volume (volumen de datos) es la pieza clave. Es como guardar archivos importantes en la nube en lugar del disco local del portátil.

Cuando montas un directorio del host en el contenedor con -v, los datos quedan en el host. Borras el contenedor y los datos siguen ahí; reinicias y puedes leerlos de nuevo. Por eso en producción debes montar un volumen.

En resumen:

• Sin volumen = datos dentro del contenedor = se pierden al eliminarlo
• Con volumen = datos en el host = se conservan al eliminar el contenedor

Despliegue rápido de un Redis básico

Antes de la persistencia, despleguemos el contenedor más simple para ver cómo se comporta «sin persistencia».

Arrancar el contenedor básico

Abre la terminal y ejecuta:

docker run -d --name redis-basic -p 6379:6379 redis:latest

Significado:

• -d: ejecutar en segundo plano
• --name redis-basic: nombre del contenedor
• -p 6379:6379: mapear el puerto 6379 del contenedor al host
• redis:latest: imagen Redis más reciente

Docker descargará la imagen si no la tienes y arrancará el contenedor.

Comprobar que el contenedor funciona

docker ps

Si redis-basic aparece como Up, el contenedor está en marcha.

Entra y prueba lectura/escritura:

docker exec -it redis-basic redis-cli

Dentro de redis-cli:

set test "hello"
get test

Si devuelve "hello", Redis responde correctamente.

Problemas de esta versión básica

Parece bien, pero tiene tres fallos graves:

1. Sin persistencia: al reiniciar el contenedor, los datos se pierden
2. Sin contraseña: cualquiera puede conectarse y leer/escribir
3. Configuración por defecto: no puedes ajustar memoria, persistencia, etc.

Prueba a reiniciar y comprobar si los datos siguen:

docker restart redis-basic
docker exec -it redis-basic redis-cli
get test

Lo más probable es que la clave test ya no exista. Eso es no tener persistencia.

Configurar persistencia RDB (instantáneas)

Redis tiene dos modos de persistencia: RDB y AOF. Empezamos por RDB, más sencillo.

Railway - Plataforma de despliegue moderna, sin ops complejas, en producción en minutos

Empezar ahora →Anuncio

¿Qué es RDB?

RDB significa Redis Database: una «instantánea» de la base de datos. Cada cierto tiempo Redis guarda todo el estado en un archivo dump.rdb.

Ventaja: recuperación rápida. Inconveniente: puedes perder datos desde la última instantánea. Si guardas cada 5 minutos, en el peor caso pierdes hasta 5 minutos de escrituras.

Parámetros de RDB

RDB se controla con save:

save <segundos> <número de keys modificadas>

Ejemplos:

• save 900 1: en 900 s (15 min), si al menos 1 key cambió, guardar instantánea
• save 300 10: en 300 s (5 min), si al menos 10 keys cambiaron, guardar
• save 60 10000: en 60 s, si al menos 10000 keys cambiaron, guardar

Las reglas son en relación «o»: basta cumplir una para disparar el guardado.

Montar volumen para persistir

Configurar RDB no basta; hay que montar el volumen en el host para que dump.rdb sobreviva al contenedor.

Crea el directorio de datos:

mkdir -p ~/redis-data

Arranca Redis con volumen:

docker run -d \
  --name redis-rdb \
  -p 6379:6379 \
  -v ~/redis-data:/data \
  redis:latest \
  redis-server --save 60 1 --dir /data

Puntos clave:

• -v ~/redis-data:/data: monta ~/redis-data del host en /data del contenedor
• --save 60 1: guardar si al menos 1 key cambia en 60 s (para pruebas; en producción sube el intervalo)
• --dir /data: ruta del archivo RDB

Verificar que la persistencia funciona

docker exec -it redis-rdb redis-cli
set user:1 "Juan"
set user:2 "Ana"

Espera 60 segundos para que Redis guarde la instantánea. Reinicia:

docker restart redis-rdb

Comprueba de nuevo:

docker exec -it redis-rdb redis-cli
get user:1

Si devuelve "Juan", la persistencia está bien.

En ~/redis-data del host deberías ver dump.rdb, el archivo de instantánea.

Configurar persistencia AOF (registro append-only)

RDB es simple, pero puede perder datos desde la última instantánea. Si la seguridad de datos es crítica, usa AOF.

¿Qué es AOF?

AOF significa Append Only File. Cada operación de escritura (set, del, incr, etc.) se añade a appendonly.aof.

Analogía: RDB es una foto; AOF es una grabación en vídeo. RDB hace fotos periódicas; AOF registra cada acción.

Ventaja: más seguridad; con everysec pierdes como mucho 1 segundo. Inconveniente: archivos más grandes y recuperación algo más lenta.

Tres estrategias de sincronización AOF

1. appendfsync always: sincroniza al disco en cada escritura

   • Máxima seguridad, casi sin pérdida
   • Peor rendimiento; no ideal en alta concurrencia

2. appendfsync everysec: sincroniza cada segundo (recomendado)

   • Equilibrio rendimiento/seguridad
   • Pérdida máxima ~1 segundo
   • Uso habitual en producción

3. appendfsync no: el SO decide cuándo sincronizar

   • Mejor rendimiento
   • Puede perder más datos; no recomendado

Arrancar Redis con AOF

mkdir -p ~/redis-data

docker run -d \
  --name redis-aof \
  -p 6379:6379 \
  -v ~/redis-data:/data \
  redis:latest \
  redis-server --appendonly yes --appendfsync everysec --dir /data

Parámetros clave:

• --appendonly yes: activa AOF
• --appendfsync everysec: sincronización cada segundo
• --dir /data: directorio de datos

Tras un rato, en el directorio de datos verás appendonly.aof:

ls ~/redis-data/

Persistencia híbrida (recomendada desde Redis 4.0+)

Desde Redis 4.0, Redis recomienda modo híbrido, combinando RDB y AOF:

• RDB para recuperación rápida
• AOF para seguridad de datos

En el archivo de configuración:

aof-use-rdb-preamble yes

Al reiniciar, Redis carga primero la instantánea RDB (rápido) y luego reproduce el AOF incremental posterior a esa instantánea.

Si usas Redis 4.0 o superior, el modo híbrido suele ser la mejor opción; no hace falta elegir solo RDB o solo AOF.

Gestionar Redis con archivo de configuración (recomendado en producción)

Hasta ahora usamos parámetros en línea de comandos (--appendonly yes, etc.). Con muchos parámetros el comando se alarga y es difícil de mantener.

En producción lo habitual es un archivo de configuración.

¿Por qué un archivo de configuración?

• Toda la config en un solo sitio
• Fácil de versionar (Git)
• El equipo comparte la misma config
• Cambios sin reescribir comandos largos

Si Redis va a correr a largo plazo, merece la pena un redis.conf dedicado.

Obtener la plantilla oficial

mkdir -p ~/redis-config
docker run --rm redis:latest cat /etc/redis/redis.conf > ~/redis-config/redis.conf

Eso guarda la config por defecto en ~/redis-config/redis.conf.

Personalizar redis.conf

Abre redis.conf y ajusta:

1. Red

# Permitir conexiones desde cualquier IP (en producción, mejor IP de red interna)
bind 0.0.0.0

# Desactivar modo protegido (tras activar contraseña)
protected-mode no

2. Autenticación

# Contraseña de acceso
requirepass YourStrongPassword123

3. Persistencia

# RDB
save 900 1
save 300 10
save 60 10000
dbfilename dump.rdb

# AOF
appendonly yes
appendfilename "appendonly.aof"
appendfsync everysec

# Híbrido (Redis 4.0+)
aof-use-rdb-preamble yes

# Directorio de datos
dir /data

4. Memoria máxima

# Límite de 512 MB
maxmemory 512mb

# Política: eliminar keys menos usadas recientemente
maxmemory-policy allkeys-lru

5. Logs

# Niveles: debug, verbose, notice, warning
loglevel notice

# Ruta del log (cadena vacía = stdout)
logfile ""

Arrancar con el archivo de configuración

docker run -d \
  --name redis-prod \
  -p 6379:6379 \
  -v ~/redis-config/redis.conf:/usr/local/etc/redis/redis.conf \
  -v ~/redis-data:/data \
  redis:latest \
  redis-server /usr/local/etc/redis/redis.conf

redis-server /usr/local/etc/redis/redis.conf indica a Redis qué archivo usar.

Verificar la configuración

docker exec -it redis-prod redis-cli -a YourStrongPassword123
config get save
config get appendonly
config get maxmemory

Si los valores coinciden con redis.conf, la config está activa.

Autenticación por contraseña en Redis (3 métodos)

Caso real: una empresa dejó Redis sin contraseña expuesto en Internet. Fue comprometido y el servidor se usó para minar criptomonedas. No es un chiste.

Vultr - Servidor cloud NVMe de alto rendimiento, 32 ubicaciones globales, despliegue Docker con un clic

Ver precios →Anuncio

¿Por qué es obligatoria la contraseña?

Redis no trae contraseña por defecto. Si el puerto está en Internet o la red interna no es de confianza, sin contraseña es dejar la puerta abierta.

En producción, contraseña es requisito mínimo.

Método 1: parámetro en línea de comandos

docker run -d \
  --name redis-pwd \
  -p 6379:6379 \
  redis:latest \
  redis-server --requirepass "MyStr0ng#P@ssw0rd"

Sirve para pruebas rápidas; no para producción: la contraseña queda en el historial del shell.

Método 2: archivo de configuración (recomendado)

En redis.conf:

requirepass YourStrongPassword123

Monta el archivo como antes. Es el estándar en producción: la contraseña no aparece en el historial y el equipo puede gestionarla.

Recomendaciones de complejidad:

• Mínimo 16 caracteres
• Mayúsculas, minúsculas, números y símbolos
• Evitar palabras comunes o fechas de cumpleaños

Método 3: cambio dinámico dentro del contenedor

Si el contenedor ya corre y necesitas cambiar la contraseña al vuelo:

docker exec -it redis-pwd redis-cli
config set requirepass "NewPassword123"

Se pierde al reiniciar; solo para emergencias, no uso permanente.

Conectar con contraseña

Opción 1: contraseña en la línea de comandos

docker exec -it redis-pwd redis-cli -a "MyStr0ng#P@ssw0rd"

Opción 2: conectar y luego AUTH

docker exec -it redis-pwd redis-cli
auth MyStr0ng#P@ssw0rd
set test "hello"

Si la contraseña falla:

(error) NOAUTH Authentication required.

Usa auth de nuevo con la contraseña correcta.

Configuración en aplicaciones

Cadena de conexión con contraseña:

redis://:YourStrongPassword123@localhost:6379

O en código:

// Ejemplo Node.js
const redis = require('redis');
const client = redis.createClient({
  host: 'localhost',
  port: 6379,
  password: 'YourStrongPassword123'
});

Despliegue con Docker Compose (recomendado en equipo)

Todo lo anterior usa docker run. El inconveniente: comandos largos que hay que repetir.

En equipo o con varios contenedores, Docker Compose suele ser mejor.

¿Por qué Docker Compose?

• Config en docker-compose.yml, versionable
• Arranque con un comando
• Mismo entorno para todo el equipo
• Varios servicios (Redis + MySQL + Nginx) en un solo archivo

docker-compose.yml completo

version: '3.8'

services:
  redis:
    image: redis:7.2-alpine
    container_name: redis-prod
    restart: always
    ports:
      - "6379:6379"
    volumes:
      - ./redis-config/redis.conf:/usr/local/etc/redis/redis.conf
      - ./redis-data:/data
    command: redis-server /usr/local/etc/redis/redis.conf
    healthcheck:
      test: ["CMD", "redis-cli", "ping"]
      interval: 10s
      timeout: 3s
      retries: 3

volumes:
  redis-data:
    driver: local

Notas:

• image: redis:7.2-alpine: imagen Alpine ligera
• restart: always: reinicio automático si falla
• volumes: config y datos
• healthcheck: comprobación cada 10 s

Arranque con un comando

docker-compose up -d

-d es segundo plano. Compose crea red, monta volúmenes y arranca el contenedor.

Estado

docker-compose ps

Logs

docker-compose logs -f redis

-f sigue el flujo de logs (como tail -f).

Parar

docker-compose down

Para y elimina contenedores; no borra volúmenes (los datos permanecen).

Reiniciar

docker-compose restart redis

Ampliar el stack

Si hay más servicios en el mismo proyecto:

version: '3.8'

services:
  redis:
    # Configuración Redis...

  mysql:
    image: mysql:8.0
    # Configuración MySQL...

  app:
    build: .
    # Configuración de la app...
    depends_on:
      - redis
      - mysql

Al levantar el proyecto, Redis, MySQL y la app arrancan juntos con dependencias resueltas.

Resolución de problemas y buenas prácticas

Aunque Redis esté en marcha, surgirán dudas. Aquí, problemas frecuentes y prácticas de producción.

Ver logs de Redis

Ante un problema, mira los logs primero.

Últimas 100 líneas:

docker logs --tail 100 redis-prod

Seguimiento continuo:

docker logs -f redis-prod

Con Docker Compose:

docker-compose logs -f redis

Los logs indican si el arranque fue correcto, si hay errores en la config o conexiones anómalas.

Healthcheck del contenedor

Docker puede comprobar si Redis responde y marcar el contenedor como no saludable.

En docker-compose.yml:

healthcheck:
  test: ["CMD", "redis-cli", "ping"]
  interval: 10s
  timeout: 3s
  retries: 3

Cada 10 s ejecuta redis-cli ping; tras 3 fallos seguidos, el contenedor queda «unhealthy».

Con restart: always, un contenedor no saludable puede reiniciarse automáticamente.

Optimización de rendimiento

1. Limitar memoria máxima

KiloClaw - OpenClaw gestionado para empresas: orquestación de agentes IA y enrutamiento inteligente

Empezar →Anuncio

Redis puede consumir toda la RAM disponible; en producción conviene un tope:

maxmemory 512mb
maxmemory-policy allkeys-lru

allkeys-lru elimina las keys menos usadas recientemente cuando se llena la memoria.

2. Deshabilitar comandos peligrosos

Comandos arriesgados en producción:

• FLUSHALL: borra todas las bases
• FLUSHDB: borra la base actual
• KEYS *: lista todas las keys y puede bloquear Redis

En redis.conf:

rename-command FLUSHALL ""
rename-command FLUSHDB ""
rename-command KEYS ""

3. Ajustar frecuencia de RDB

Con mucha escritura, puedes espaciar las instantáneas:

save 900 1
save 300 10
save 60 10000

Valores por defecto razonables para muchos casos. Si Redis es sobre todo caché y toleras pérdida, puedes relajar más.

Refuerzo de seguridad

1. No exponer a Internet

Redis no debería estar abierto al mundo. Para acceso remoto, túnel SSH o VPN.

Enlazar solo IPs internas:

bind 127.0.0.1 192.168.1.100

2. Contraseña fuerte

Mínimo 16 caracteres, mix de tipos:

requirepass Th1s!sA$tr0ngP@ssw0rd2024

3. Copias de seguridad periódicas

Aunque tengas persistencia, programa backups. Script diario que copie dump.rdb y appendonly.aof:

#!/bin/bash
DATE=$(date +%Y%m%d)
cp ~/redis-data/dump.rdb ~/redis-backup/dump-$DATE.rdb
cp ~/redis-data/appendonly.aof ~/redis-backup/appendonly-$DATE.aof

Lista de verificación para producción

Antes de desplegar, revisa:

• ✅ Persistencia configurada (recomendado: híbrido RDB+AOF)
• ✅ Autenticación por contraseña activa
• ✅ Volumen montado en el host
• ✅ Config personalizada (no predeterminada)
• ✅ Logs accesibles
• ✅ Healthcheck configurado
• ✅ Memoria máxima limitada
• ✅ Comandos peligrosos deshabilitados o renombrados
• ✅ Estrategia de backup definida
• ✅ Sin exposición pública (o con VPN/túnel SSH)

Monitorizar rendimiento

Memoria:

docker exec -it redis-prod redis-cli -a your_password
info memory

Persistencia:

info persistence

Conexiones:

info clients

Si llegaste hasta aquí, deberías tener un contenedor Redis de nivel producción: datos persistentes, contraseña y configuración ordenada.

Conclusión

Volvamos al escenario inicial: Redis desplegado el viernes por la noche y el lunes por la mañana todo perdido. Ya sabes por qué: sin persistencia, los datos vivían solo dentro del contenedor y el reinicio los borró.

Este artículo cubre la solución completa:

• RDB: instantáneas periódicas, recuperación rápida, bueno para backups
• AOF: registro de escrituras, alta seguridad, pérdida máxima ~1 s
• Híbrido (recomendado): combina velocidad de RDB y seguridad de AOF
• Contraseña: tres formas de configurarla; obligatoria en producción
• Archivo de configuración: despliegue mantenible en equipo
• Docker Compose: un comando, configuración como código

Si ya usas Redis en Docker, comprueba ahora:

1. ¿Montaste el volumen? (-v ~/redis-data:/data)
2. ¿Activaste persistencia? (RDB, AOF o híbrido)
3. ¿Pusiste contraseña? (requirepass)
4. ¿Personalizaste la config? (no la predeterminada)

En producción, estos cuatro puntos son el mínimo. Con ellos reduces mucho el riesgo de pérdida de datos y acceso no autorizado.

Guarda este artículo para la próxima vez que despliegues Redis. Si tu equipo también usa Docker para Redis, compártelo para unificar criterios y evitar trampas repetidas.

Las configuraciones de este artículo están basadas en Redis 7.x. Si usas otra versión, consulta la documentación oficial de Redis por si algún parámetro cambió.