Redis in Docker Compose With Persistence: The Setup That Does Not Quietly Eat Your Data
A practical Redis and Docker Compose guide that shows how to run Redis locally with persistence, explain the difference between ephemeral and durable local state, and avoid the setup mistakes that erase data unexpectedly.
Why this bites developers: Redis feels lightweight, so people start it casually, store useful local state in it, and then act surprised when the container disappears and the data goes with it.
The default local Redis mistake
A quick setup like this is common:
services:
redis:
image: redis:7
ports:
- "6379:6379"It starts fast. It also teaches the wrong lesson. If you rely on that state later, you have built something disposable without admitting it.
Decide what local Redis is for
There are two honest modes:
- fully disposable cache for short-lived local testing
- semi-persistent local state you expect to survive restarts
Both are valid. Confusion starts when you think you are in the second mode but your config is really the first.
A more durable local setup
services:
redis:
image: redis:7
ports:
- "6379:6379"
command: ["redis-server", "--appendonly", "yes"]
volumes:
- redis_data:/data
volumes:
redis_data:This does two important things:
- enables append-only persistence
- stores Redis data in a named Docker volume
That is the difference between “a process is running” and “this local service has memory.”
Why docker compose down surprises people
Depending on how you bring the stack down, containers vanish but named volumes may survive. That is good if you want persistence. It is bad if you did not understand what was being kept.
The key is to stop treating Docker state as magic. Containers, images, and volumes are different things.
A useful verification step
Start the service:
docker compose up -dThen connect:
redis-cli -p 6379Set a key:
SET demo "hello"Restart the service and read it back:
GET demoIf the value survives, your local persistence story is actually working.
Common local Redis misunderstandings
“The container restarted, so my data should still be there”
Not unless you configured persistence properly.
“A volume means I never lose data”
Not if you delete the volume or replace it carelessly.
“Redis is only a cache, so none of this matters”
That depends entirely on how your local workflow uses it.
When disposable Redis is still fine
If you are testing ephemeral queue behavior or short-lived cache invalidation logic, a throwaway Redis container is perfectly reasonable. The problem is not disposability. The problem is accidental disposability.
Final recommendation
With Redis in Docker Compose, pick a truth and encode it. If the service is disposable, accept that. If the data should survive, configure persistence and test it like you mean it. Local infra gets much easier once your expectations match the container lifecycle.
That alignment matters more than the specific YAML. Most painful local Redis setups are not technically advanced mistakes. They are expectation mistakes. People think they are building a durable local dependency when they are really spinning up a forgetful helper process.
Once you test restart behavior on purpose, Redis becomes much easier to trust. Local infrastructure should not rely on wishful thinking. It should rely on one or two explicit checks that prove the persistence story is actually real.
That is a small habit, but it prevents a lot of quiet data loss.