Skip to main content
< All Topics
Print

Chapter 7: Redis

Chapter 7: Redis

Last Updated: 2026-03

## 7.1 Overview

Redis serves two purposes in the ITI stack: it is the Celery task broker for Dify’s async worker and an application cache for the Dify API.

Container: iti-redis

Image: redis:7-alpine

Internal port: 6379 (not exposed to host)

Connection URL: redis://iti-redis:6379/0

Redis data is not backed up. All persistent business data lives in PostgreSQL. Redis holds transient state: task queues, cache entries, and short-lived session data.

7.2 Redis as Celery Broker

The Dify worker (iti-dify-worker) is a Celery application. Celery uses Redis as both:

  • Broker — where task messages are published and consumed.
  • Result backend — where task results are stored until retrieved.

When a user adds a document to a Dify knowledge base, the Dify API publishes a “process document” task to the Redis queue. The Dify worker picks it up, chunks the document, calls the embedding model, and stores the results in PostgreSQL. This async pattern prevents long-running operations from blocking the API.

How to verify the Celery broker is healthy


# Ping Redis
docker exec iti-redis redis-cli ping
# Expected: PONG

# Count pending tasks in the default queue
docker exec iti-redis redis-cli llen celery

If celery queue depth is growing continuously (> 100) and not decreasing, the Dify worker may be stuck. Restart it:


docker compose restart iti-dify-worker

7.3 Redis as Application Cache

The Dify API caches:

  • API configuration values
  • Frequently accessed dataset metadata
  • Rate limiting counters

Cache entries expire automatically (TTL-based). No manual cache management is required under normal operation.

Force a cache clear (when needed after config changes)


docker exec iti-redis redis-cli FLUSHDB

Warning: FLUSHDB clears all Redis data including the Celery task queue. Only run this when no tasks are in-flight (i.e., no documents are being indexed). Verify with docker exec iti-redis redis-cli llen celery first.


7.4 Redis Operations Reference

Basic health and info


# Ping
docker exec iti-redis redis-cli ping

# Server info (version, memory, clients)
docker exec iti-redis redis-cli info server

# Memory usage
docker exec iti-redis redis-cli info memory

# Connected clients
docker exec iti-redis redis-cli info clients

Key management


# Count all keys
docker exec iti-redis redis-cli dbsize

# List keys matching a pattern (use with caution in production)
docker exec iti-redis redis-cli keys "celery*"

# Get the value of a key
docker exec iti-redis redis-cli get <key>

# Check TTL of a key
docker exec iti-redis redis-cli ttl <key>

Queue depth monitoring


# Celery default queue depth
docker exec iti-redis redis-cli llen celery

# All queue names
docker exec iti-redis redis-cli keys "*queue*"

7.5 Redis Monitoring Thresholds

Metric Normal Investigate
Memory used < 500 MB > 1 GB
Connected clients < 20 > 50
Celery queue depth < 10 > 100 (and growing)
Blocked clients 0 > 0

Check memory and client counts:


docker exec iti-redis redis-cli info | grep -E "used_memory_human|connected_clients|blocked_clients"

7.6 Redis Upgrades

Redis uses redis:7-alpine. Patch updates within Redis 7 are backward-compatible — a docker compose pull and up -d is sufficient.

For major version upgrades (Redis 7 → 8):

  1. Follow the pre-upgrade checklist in Chapter 5.
  2. Redis AOF persistence files are backward-compatible across minor versions; test compatibility before committing to a major upgrade.
  3. After upgrade, verify redis-cli ping and Celery queue health.

Previous: Chapter 6 — PostgreSQL & pgvector | Next: Chapter 8 — Nginx Reverse Proxy

Table of Contents