Infrastructure guide
Redis Docker Compose: Choose Persistence Before Production
Classify Redis as cache or record before choosing RDB, AOF, networking, ACLs, memory limits, backups, and restore behavior.
Published and reviewed by OpenAlt · October 1, 2026
OpenAlt’s verdict: classify Redis before writing Compose. For a disposable cache, choose simplicity, bounded memory, private networking, and no persistence. For a system of record, choose RDB, AOF, or both against explicit recovery objectives, retain off-host copies, and rehearse restoration. Durability adds storage and recovery work; convenience can turn a restart into data loss.
Table of Contents
- Classify Redis as disposable cache or system of record
- Private service with pinned version, volume, healthcheck and no public 6379
- RDB, AOF, both and none as recovery objectives
- ACL/auth and application boundaries
- Memory limits and eviction consequences
- Consistent off-host backups and isolated restore
- Compatibility-aware upgrade and rollback
- Failure checks for data loss, refusal, OOM, latency and corruption
- FAQ
Classify Redis as disposable cache or system of record before Compose
Treat Redis as a disposable cache only when the application can safely rebuild its contents. Otherwise, treat it as a system of record and design persistence, backups, and restoration around explicit loss tolerance.
- A cache may tolerate empty data after replacement or restart.
- A system of record needs defined recovery point and recovery time objectives.
- If keyspaces have different consequences, document those boundaries instead of assigning one label to the service.
- If ownership is uncertain, assume the data matters until the application owner confirms otherwise.
Do not let “cache” settle the decision. Sessions, queues, rate limits, locks, and derived data may each have different consequences when absent or stale. Record what can be rebuilt, replayed, or preserved.
Use the RTO/RPO impact calculator to turn the classification into targets. Redis documents RDB, AOF, no persistence, and combinations of these modes, so the choice belongs in the recovery plan. Redis persistence documentation
Private service with pinned version, volume, healthcheck and no public 6379
A production-minded Redis service should pin its image version, use a named volume when persistence is required, define a healthcheck, and expose port 6379 only to the application network.
- Pin the image reference so deployments do not silently change the server version.
- Use a named volume and make its ownership and lifecycle explicit.
- Add a healthcheck for the condition the application actually needs.
- Keep Redis on an internal Compose network unless an external client is required.
- Avoid publishing 6379 to the host or public interface by default.
A healthcheck is not a backup, and a named volume is not an off-host copy. They provide readiness and local durability, respectively. Docker Compose getting-started documentation
RDB, AOF, both and none as recovery objectives
Choose persistence by the loss you can accept, not by habit. Redis documents all four modes: none for disposable data, RDB for snapshot-oriented recovery, AOF for write-history-oriented recovery, and both when added storage and procedures are justified.
| Mode | Practical fit | Main decision |
|---|---|---|
| None | Rebuildable cache | Confirm empty state is acceptable |
| RDB | Snapshot-based recovery | Define the acceptable snapshot gap |
| AOF | More write-history-oriented recovery | Define retention and replay handling |
| Both | Stronger recovery flexibility | Accept extra storage and procedures |
These are recovery choices, not guarantees. Specify how much data may be lost, how quickly service must return, where copies live, and who validates restored application state. Redis persistence documentation
For a disposable cache, persistence may add work without reducing meaningful risk. For important data, select the mode that matches the recovery procedure and test that procedure independently from the Compose deployment.
ACL/auth and application boundaries
Keep Redis on a trusted network, protect access with authentication controls, and use ACLs to separate applications or roles where justified. Compose networking should reinforce that boundary rather than making Redis broadly reachable.
- Give each application its own Redis identity where feasible.
- Grant only needed commands and key patterns.
- Separate administrative access from application access.
- Treat credentials as deployment secrets, not documentation or shell-history values.
- Define ownership for each database, prefix, stream, or keyspace.
An ACL boundary is useful only when the application boundary is clear. Keep the network private even when authentication is enabled because layered controls reduce exposure consequences. Redis security documentation
Memory limits and eviction consequences
Set explicit memory limits and choose an eviction policy before Redis reaches the boundary. Eviction may be acceptable for a cache, but it can violate correctness when keys represent durable state, pending work, locks, or information that cannot disappear.
- Define Redis’s maximum memory budget and leave room for the surrounding service.
- Decide what may be evicted and what must cause refusal or alerting.
- Monitor pressure, rejected writes, evictions, and latency together.
- Document whether out-of-memory should degrade, fail closed, or trigger recovery.
- Revisit the policy when key sizes, retention, or workload changes.
For a cache, eviction may be expected. For a system of record, it is a data-integrity decision requiring an application response. Redis memory optimization documentation
Consistent off-host backups and isolated restore
A local named volume is not disaster recovery. Produce a consistent backup for the selected persistence mode, copy it off the host, and restore it into an isolated Redis service before trusting the procedure.
- Define the source artifact, retention, and expected recovery point.
- Produce the copy using a method compatible with the persistence mode.
- Transfer it to separate storage with access controls and retention.
- Restore it into an isolated Compose project or equivalent environment.
- Verify expected keys, application behavior, and recovery timing.
- Record failures and update the runbook.
The isolated restore matters because an existing file does not prove that the application can use it. Validate without allowing the restored service to receive production writes. The backup storage calculator can estimate retention needs; Redis persistence documentation covers off-host copy guidance.
Compatibility-aware upgrade and rollback
Pin versions, review compatibility before changing them, and make rollback depend on a verified backup. Identify the image change, persistence artifacts, client expectations, migration order, health criteria, and point at which rollback is no longer safe.
- Record the current image reference and configuration.
- Back up data before changing the service.
- Validate the target version with the application’s commands and data model.
- Upgrade in a reversible sequence with an explicit stop condition.
- Keep the previous image reference until recovery checks pass.
- Do not roll back blindly if the newer process changed persistence artifacts.
Compose makes service definition repeatable, but not compatibility automatic. Treat image version, configuration, persistence format, and client behavior as one change set. State what happens to writes accepted during the attempted upgrade.
Failure checks for data loss, refusal, OOM, latency and corruption
Check Redis and the application for missing data, refused writes, memory exhaustion, rising latency, unhealthy status, and unreadable persistence artifacts. Run the checks against the actual Compose configuration and recovery path, recording the expected signal and operator response.
- Confirm a cache can rebuild without manual repair.
- Confirm important data survives the selected restart and restore path.
- Confirm unauthorized clients cannot connect through published interfaces.
- Confirm healthcheck failure prevents dependent traffic from being treated as ready.
- Confirm memory pressure produces documented eviction or refusal behavior.
- Confirm latency alerts distinguish saturation from application failure.
- Confirm damaged or incomplete backups are detected before restoration.
- Confirm the rollback decision has an owner and stopping condition.
OpenAlt’s database and spreadsheet resources support the wider operating model. Pair the decision with Grafana in Docker Compose for observability, and use the RTO/RPO impact calculator to keep recovery expectations explicit. These resources do not replace restore validation.
FAQ
Align Redis configuration with the consequence of data loss, then verify it through private networking, memory controls, backups, and isolated recovery.
Is Redis without persistence suitable for production?
Yes, when Redis is genuinely a disposable cache and the application can rebuild its contents. Document the rebuild path and confirm temporary loss does not violate application correctness.
Should a system of record use RDB, AOF, or both?
Choose the mode that matches the recovery objective and operational capability. Define acceptable loss, restoration time, retention, and off-host copies, then validate the complete restore procedure. Redis persistence documentation
Does a named Docker volume provide disaster recovery?
No. It provides persistent storage for the Compose service but remains tied to the host and deployment environment. Create consistent off-host copies and test restoring them in isolation. Docker Compose getting-started documentation
What should happen when Redis reaches its memory limit?
The response should match the data classification. A cache may use planned eviction, while important data may require refusal, alerting, or service protection. Define, monitor, and test that consequence before production pressure occurs. Redis memory optimization documentation