How to Run Redis in Docker Compose With Persistence and Auth

Before you begin

• Docker and Docker Compose installed.
• A Compose app directory such as ~/apps/myapp.
• A clear reason to use Redis, such as caching, queueing, or sessions.
• A safe place to store the Redis password outside version control.

Redis is fast and useful, but it is easy to deploy carelessly. Many tutorials expose port 6379 publicly, skip authentication, and treat persistence like an afterthought. That is fine for a disposable local test. It is not fine for a VPS that other services depend on.

Step 1: Understand whether Redis data needs persistence

Some Redis use cases are disposable, such as a pure cache that can be rebuilt. Others matter a lot more, such as job queues, rate limiter state, or sessions. Decide that early, because it affects how seriously you treat persistence and backup.

For most self-hosted app stacks, a named volume plus append-only persistence is a practical default.

Step 2: Build a Compose service with persistence and auth

Create a local env file:

REDIS_PASSWORD=replace-this-with-a-long-random-value

Then use a Compose file like this:

services:
  redis:
    image: redis:7-alpine
    restart: unless-stopped
    command:
      - redis-server
      - --appendonly
      - "yes"
      - --requirepass
      - ${REDIS_PASSWORD}
    env_file:
      - .env
    volumes:
      - redis-data:/data
    healthcheck:
      test: ["CMD-SHELL", "redis-cli -a \"$$REDIS_PASSWORD\" ping | grep PONG"]
      interval: 15s
      timeout: 5s
      retries: 5
    mem_limit: 256m
    cpus: 0.50

volumes:
  redis-data:

This does a few important things:

• Stores data in a named volume.
• Enables AOF persistence with --appendonly yes.
• Requires a password.
• Leaves Redis unexposed to the public host by default because there is no ports: section.

Bring it up:

docker compose config
docker compose up -d

Expected outcome: Redis starts, writes data to a persistent volume, and refuses unauthenticated commands.

Step 3: Verify Redis and connect your app

Check container status and logs:

docker compose ps
docker compose logs --tail=100 redis

Test authentication from inside the container:

docker compose exec redis redis-cli -a "$REDIS_PASSWORD" ping

You should get PONG. Then point your app at Redis using an internal Compose hostname like redis. Many apps accept a URL such as:

redis://:your-password@redis:6379/0

If the app lives in the same Compose project, it can usually reach Redis by service name automatically.

Step 4: Rollback and recovery notes

Redis is often lower-stakes than a primary database, but recovery still matters. A safe baseline is:

• Back up the named volume if Redis holds anything you cannot casually lose.
• Keep the previous image tag if you update Redis later.
• Know whether your app can tolerate a cold cache rebuild or missing queue items.

Useful commands:

docker volume ls
docker compose images
cp compose.yml compose.yml.bak-$(date +%F-%H%M)

If a Redis update breaks, revert the image tag and redeploy. If the data also became unusable, restore the volume backup or accept a clean rebuild if your workload allows it.

Troubleshooting common Redis mistakes

The app cannot connect.
Confirm the app is using the service name redis, the correct port 6379, and the correct password.

The healthcheck keeps failing.
Make sure the password is reaching the container correctly and that redis-cli exists in the image. The official image includes it.

Redis lost data after recreation.
Check whether the named volume was attached correctly and whether the Compose project name changed, which can create a different volume name.

I need host access for local debugging.
If you temporarily publish a port like 127.0.0.1:6379:6379, keep it bound to localhost, not 0.0.0.0, and remove it when you are done.

What to do next

Once Redis is solid, the next maturity step is protecting the whole stack with safer update habits. Continue with How to Update Docker Compose Apps Safely With Rollbacks.