Bound to every interface
The one that turns a data leak into remote code execution. CONFIG SET dir plus SAVE writes a file anywhere Redis can write, so an exposed port with no password is enough.
- role
- cache
- bind
- 0.0.0.0
- maxmemory
- 4gb
Describe the instance and get a redis.conf with a comment above every directive saying why it has that value. Nothing here writes a password into the file, deliberately: a generated credential outlives every rotation policy.
Worked setups you can load into the form above. Each one is a decision the generator makes differently, and the reason it makes it.
The one that turns a data leak into remote code execution. CONFIG SET dir plus SAVE writes a file anywhere Redis can write, so an exposed port with no password is enough.
noeviction on a cache, which is the Redis default and so arrives by omission rather than by choice. Reads keep working while every write fails with OOM.
Snapshots alone lose every write since the last one. That is correct for a cache and is data loss for anything else.
These are the ones that fail silently. The config is accepted, nothing raises an error, and the consequence arrives later.
Replication buffers, client buffers and the fork during a save all live outside that limit, so resident memory goes above it and the kernel kills the process.
Instead:Leave 30 to 40 percent free.
The default is noeviction. Writes start failing at the limit while reads keep working, so the instance looks healthy and stops caching anything new.
Instead:Set allkeys-lru or allkeys-lfu explicitly.
The credential is then in the repository history, and it outlives every rotation. Removing the line later does not remove it from history.
Instead:Inject it at runtime from a secret store.
CONFIG SET applies immediately and is lost on restart unless CONFIG REWRITE is run. A setting fixed during an incident quietly reverts.
Instead:Run CONFIG REWRITE, or change the file and restart.
A stock redis.conf is tuned for starting up on a laptop, not for the job you are giving it. These four are the ones that cause incidents.
With no limit Redis grows until the machine runs out and the kernel kills it. There is no warning stage: the process disappears. Setting a limit turns an OOM kill into an eviction, which is a policy decision rather than an outage.
It arrives by omission rather than by choice, and on a cache it is wrong. At the limit, reads keep working while every write fails with an OOM error, so the cache stops accepting new entries and quietly stops being useful while looking healthy.
RDB snapshots are point in time, so everything written since the last one is gone. If the data can be rebuilt from somewhere else that is fine. If it cannot, it is data loss on an ordinary restart.
Replication buffers, client output buffers and the copy-on-write of a background save all sit outside maxmemory. An instance set to the full machine size is reliably OOM killed during a save, which is the moment it is doing the most work.
It cannot see your workload, your key sizes or your network. The numbers here are a defensible starting point with the reasoning attached, not a measurement. Check maxmemory against real usage once the instance has run under load.