Redis Docker Compose: The Complete Setup and Caching Guide

Disclosure: This post contains one or more links to providers we have a real, registered affiliate/referral relationship with. We may earn a commission at no extra cost to you if you sign up through them.

Adding a cache layer used to mean provisioning a separate service, wiring up network rules, and hoping the versions matched. A Redis Docker Compose setup collapses all of that into a few lines of YAML: one service block, one shared network, and Redis is reachable from every other container in your stack by name.

This guide walks through a production-ready Redis Docker Compose configuration, how to persist data across restarts, how to secure the connection with a password, and the mistakes that cause the most confusion when people wire Redis into an existing Postgres Docker Compose stack.

What a Redis Docker Compose Setup Actually Gives You

At its simplest, a Redis Docker Compose service is just an image reference and a port:

“yaml
services:
cache:
image: redis:7-alpine
ports:
- "6379:6379"
`

`yaml
services:
api:
build: .
environment:
- REDIS_URL=redis://:$REDIS_PASSWORD@cache:6379
depends_on:
cache:
condition: service_healthy

volumes:
redis_data:
`

Every other service resolves the cache by its Compose service name, cache:6379, because Compose gives the project its own internal bridge network automatically. That's the core advantage of a Redis Docker Compose deployment over running docker run redis by hand.

Without a healthcheck, depends_on only waits for the Redis container to start, not for the Redis server inside it to finish loading. The condition: service_healthy clause blocks the api service until redis-cli ping actually succeeds.

`bash
docker compose exec cache redis-cli -a $REDIS_PASSWORD set healthcheck ok
docker compose down
docker compose up -d
docker compose exec cache redis-cli -a $REDIS_PASSWORD get healthcheck
`

If the second get returns ok, your Redis Docker Compose volume is correctly mounted and persistence is active.

Once your Redis Docker Compose service is stable, docker compose down is the safe way to stop it without touching the redis_data volume. Our guide to Docker Compose environment variables covers .env file precedence in more depth.

`bash
docker compose exec cache redis-cli -a $REDIS_PASSWORD info memory
docker compose exec cache redis-cli -a $REDIS_PASSWORD info stats
`

The info memory output shows used_memory_human and maxmemory_human; if the two are converging, it's time to either raise the container's memory limit or tighten your maxmemory-policy. The info stats output includes keyspace_hits and keyspace_misses — a rising miss ratio over time usually means your cache TTLs are too short or your working set has outgrown the box.

`yaml
cache:
image: redis:7-alpine
deploy:
resources:
limits:
memory: 512M
`

Combined with maxmemory 400mb inside the command: block, this keeps a single Redis Docker Compose service from taking down its neighbors when key eviction alone isn't fast enough.

Redis ships with 16 numbered logical databases (0-15) inside a single instance, selectable with SELECT n from redis-cli. For a small Redis Docker Compose stack running a cache and a job queue side by side, putting each on its own numbered database avoids a FLUSHDB in one context accidentally wiping the other. For anything beyond a handful of services, most teams prefer key prefixing (session:, queue:, cache:) over numbered databases, since prefixes show up clearly in monitoring dashboards while a bare database number does not.

Do I need a separate Dockerfile for Redis in a Docker Compose stack?
No. Use the official redis:7-alpine image directly in your Redis Docker Compose file — you only need a custom Dockerfile if you're baking in custom modules that can't be passed via command: flags.

Does Redis Docker Compose data survive docker compose down?
Yes, as long as you're using a named volume and skip the -v flag. Plain docker compose down removes containers and networks but leaves volumes, and therefore your Redis data, intact.

Is it safe to run one Redis Docker Compose instance for both caching and a job queue?
Yes, as long as you isolate them with separate logical databases or key prefixes and set eviction policies that only apply to cache keys — you don't want allkeys-lru evicting queue jobs still waiting to be processed.

How much RAM does a small Redis Docker Compose service actually need?
For a low-traffic app using Redis purely for sessions and light caching, 128-256MB is typically enough; job queues holding large payloads need considerably more, and info memory is the fastest way to check actual usage rather than guessing.

A Redis Docker Compose setup is a handful of YAML lines once you know the pieces that matter: a named volume for persistence, –requirepass plus a .env` file for security, a healthcheck so dependent services wait for Redis to be truly ready, and a memory limit so one noisy cache doesn’t starve the rest of the stack. Get those right and Redis becomes a boring, reliable part of your stack instead of a source of cold-start races and vanished cache data.