Redis es el almacén de datos en memoria más usado del mundo para caché, colas y sesiones, y con Docker lo tienes funcionando en un minuto. En esta guía levantas Redis con un solo archivo docker-compose.yml, aprendes a activar la persistencia en un volumen para no perder datos al reiniciar, a protegerlo con contraseña (obligatorio en Docker) y a conectarlo como caché de otras aplicaciones. Al final comparamos Redis con Valkey, el fork libre que ha cambiado el mapa. La misma explicación está disponible en inglés.

Puntos clave

  • Redis es una base de datos clave-valor en memoria: guarda los datos en RAM, así que responde en microsegundos y se usa sobre todo como caché, cola de trabajos y almacén de sesiones.
  • Con Docker basta un servicio en docker-compose.yml; el estado se guarda en el volumen /data mediante snapshots RDB y el registro AOF, de modo que sobrevive a un reinicio del contenedor.
  • La imagen oficial trae el modo protegido desactivado para facilitar la red entre contenedores, por lo que debes ponerle contraseña con --requirepass y no publicar el puerto 6379 en Internet.
  • Fija una versión concreta de la imagen (por ejemplo redis:8.2-alpine) en lugar de :latest, para decidir tú cuándo saltas de versión mayor.
  • Desde la versión 8.0 Redis dejó de ser software libre puro; si esa licencia te preocupa, Valkey[1] es un sustituto directo con licencia BSD mantenido por la Linux Foundation.

¿Para qué se usa Redis?

Redis (REmote DIctionary Server) es un almacén de estructuras de datos en memoria creado por Salvatore Sanfilippo en 2009. A diferencia de PostgreSQL, que guarda todo en disco pensando en la durabilidad, Redis mantiene los datos en RAM y opcionalmente los persiste en disco, por lo que sus lecturas y escrituras se miden en microsegundos. Esa velocidad explica sus tres usos más habituales:

  • Caché. Guardas el resultado de una consulta cara (una página, el objeto de un usuario, una respuesta de API) con una fecha de caducidad, y la sirves desde memoria hasta que expira. Es el motivo por el que WordPress, Nextcloud o Paperless-ngx recomiendan Redis.
  • Colas y trabajos en segundo plano. Bibliotecas como Celery, Sidekiq, BullMQ o RQ usan las listas y flujos de Redis para encolar tareas (enviar correos, generar miniaturas) y procesarlas fuera de la petición web.
  • Sesiones y estado compartido. Al ser externo a la aplicación, varias réplicas de un servicio pueden compartir sesiones, contadores de límite de peticiones o cerrojos distribuidos.

Redis va mucho más allá del clásico par clave-valor: ofrece listas, conjuntos, hashes, conjuntos ordenados, streams y publicación-suscripción, todo con comandos atómicos.

El docker-compose.yml de Redis con persistencia

Crea una carpeta para el proyecto y guarda dentro este docker-compose.yml. En lugar de escribir la contraseña en el archivo, la leemos de una variable de entorno, una buena práctica que tienes explicada en la guía de variables de entorno y secretos en Docker:

services:
  redis:
    image: redis:8.2-alpine
    restart: unless-stopped
    command: >
      redis-server
      --requirepass ${REDIS_PASSWORD}
      --appendonly yes
      --appendfsync everysec
      --save 60 1000
    volumes:
      - redis_data:/data
    healthcheck:
      test: ["CMD", "redis-cli", "-a", "${REDIS_PASSWORD}", "ping"]
      interval: 30s
      timeout: 5s
      retries: 5
    networks:
      - backend

networks:
  backend:

volumes:
  redis_data:

Junto al Compose, crea un archivo .env con la contraseña (Docker Compose lo lee automáticamente). Genera una cadena larga y aleatoria, no una palabra del diccionario:

REDIS_PASSWORD=cambia_esta_clave_muy_larga_y_aleatoria

Fíjate en las opciones del command. Con --appendonly yes activas el registro AOF, que anota cada escritura; con --appendfsync everysec ese registro se vuelca a disco una vez por segundo, así que en el peor de los casos pierdes un segundo de datos. Y --save 60 1000 mantiene además los snapshots RDB: uno cada 60 segundos si ha habido al menos 1000 cambios. Todo se guarda en el volumen redis_data, montado en /data. Observa que no hay sección ports: Redis queda accesible solo dentro de la red backend, que es justo lo que quieres.

Arranca la pila y comprueba que el contenedor está sano:

docker compose up -d
docker compose ps
docker compose logs -f redis

Cuando docker compose ps muestre el estado healthy, Redis está listo. El healthcheck ejecuta redis-cli ping con la contraseña y espera un PONG.

¿Cómo proteger Redis con contraseña?

Este es el punto que más gente pasa por alto. La imagen oficial de Redis arranca con el protected mode desactivado para que otros contenedores puedan conectarse sin fricción, de modo que un Redis con el puerto 6379 publicado y sin contraseña queda abierto a cualquiera que alcance esa dirección. Ha habido campañas masivas de minado de criptomonedas que aprovechan exactamente ese descuido.

La regla es doble: pon siempre contraseña con --requirepass (como en el Compose de arriba) y no publiques el puerto salvo que lo necesites. Si de verdad tienes que acceder desde el anfitrión, ata la publicación a la interfaz local para que nunca escuche en Internet:

    ports:
      - "127.0.0.1:6379:6379"

Para entrar en la consola interactiva de Redis y probar comandos, ejecuta redis-cli dentro del contenedor y autentícate:

docker compose exec redis redis-cli
127.0.0.1:6379> AUTH cambia_esta_clave_muy_larga_y_aleatoria
OK
127.0.0.1:6379> SET saludo "hola"
OK
127.0.0.1:6379> GET saludo
"hola"

Si vas a exponer Redis fuera del servidor, la opción correcta no es abrir el puerto sino cifrar la conexión con TLS o pasarla por una red privada; publicar 6379 en abierto no es una alternativa.

Redis como caché de otras aplicaciones

Lo normal es que Redis no viva solo, sino que sea la caché de otro servicio. La conexión se hace por el nombre del servicio dentro de una red Docker compartida. Imagina que tu aplicación está en el mismo docker-compose.yml: le pasas el host redis, el puerto 6379 y la contraseña, y listo.

Un ejemplo real es Nextcloud, que usa Redis para el bloqueo transaccional de ficheros. En su Compose, el contenedor de la aplicación recibe estas variables:

    environment:
      REDIS_HOST: redis
      REDIS_HOST_PASSWORD: cambia_esta_clave_muy_larga_y_aleatoria

El patrón se repite en casi todas partes: WordPress con el plugin Redis Object Cache, Paperless-ngx como broker de tareas o Authentik para sus sesiones. Lo importante es que el host es el nombre del servicio, no localhost, y que ambos contenedores compartan una red. Como Redis no publica su puerto, solo los servicios de esa red pueden hablar con él, lo que reduce mucho la superficie de ataque.

Redis frente a Valkey: ¿cuál elegir?

Aquí conviene detenerse, porque el licenciamiento de Redis cambió. Durante quince años Redis fue software libre bajo licencia BSD. En 2024 la empresa lo relicenció a modelos source available (RSALv2 y SSPLv1), que no son licencias de código abierto reconocidas. La comunidad reaccionó bifurcando el código: nació Valkey, partiendo de la última versión libre, Redis 7.2.4, bajo la Linux Foundation y con licencia BSD.

Desde Redis 8.0 (mayo de 2025) la empresa añadió de nuevo la opción AGPLv3, así que hoy Redis se distribuye con triple licencia (RSALv2, SSPLv1 o AGPLv3) y la última versión estable es la 8.8.0. Valkey, por su parte, es un sustituto directo: habla el mismo protocolo, entiende los mismos comandos y lee los mismos ficheros de datos. Cambiar es tan sencillo como sustituir la imagen:

    image: valkey/valkey:8-alpine

¿Cuál elegir? Si quieres una licencia libre sin matices, o si tu distribución ya empaqueta Valkey por defecto (Debian, Ubuntu, Fedora y Arch lo hacen), Valkey es la apuesta segura. Si necesitas las funciones que Redis 8 reincorporó al núcleo (JSON, búsqueda, series temporales, vector sets), Redis las trae de serie mientras que en Valkey son módulos aparte. Para el 99 % de los casos de caché, cola y sesión, ambos son intercambiables.

Preguntas frecuentes

¿Redis pierde los datos si reinicio el contenedor?

No, si activas la persistencia y montas el volumen, como en el Compose de esta guía. Con --appendonly yes Redis registra cada escritura en el fichero AOF de /data, y al arrancar reconstruye el estado a partir de él. Sin volumen o sin persistencia, Redis se comporta como una caché pura y sí perdería todo al reiniciar, lo cual a veces es justo lo que quieres.

¿Necesito de verdad ponerle contraseña en una red interna?

Sí. Aunque no publiques el puerto, la contraseña es una segunda barrera barata: si otro contenedor de la red queda comprometido, o si por error acabas exponiendo 6379, --requirepass evita el acceso trivial. Es una línea en el Compose y no hay ninguna buena razón para omitirla en un despliegue serio.

¿Qué diferencia hay entre la imagen alpine y la normal?

La variante -alpine se basa en Alpine Linux y ocupa bastante menos (unos pocos megabytes frente a la imagen Debian), ideal para una caché ligera. La imagen estándar, basada en Debian, es algo mayor pero incluye más utilidades del sistema. Para Redis, que apenas necesita el sistema operativo, la versión Alpine es la opción habitual.

Conclusión

Con un único servicio en docker-compose.yml tienes un Redis rápido, persistente y protegido con contraseña, listo para servir de caché, cola o almacén de sesiones a tus demás contenedores. Recuerda las dos reglas de oro: nunca lo dejes sin contraseña y nunca publiques el puerto 6379 en abierto. El siguiente paso lógico es conectarlo a una aplicación real, como Nextcloud, y decidir con calma si te quedas con Redis o das el salto a Valkey.

Fuentes

  1. Valkey
  2. Imagen oficial redis en Docker Hub
  3. Documentación oficial de Redis: persistencia

Ruta: Bases de datos y almacenamiento self-hosted con Docker