Redis Config File Generator

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.

What this instance is for

The role changes the defaults for eviction and persistence, because a cache and a datastore want opposite answers to both.

Role A cache defaults to allkeys-lru with no AOF. A datastore defaults to noeviction with AOF on.

Memory limit Roughly 60 to 70 percent of the machine. Replication buffers, client output buffers and the fork a BGSAVE performs all sit OUTSIDE this limit, so setting it to the full machine size is reliably OOM killed during a save.

Eviction

Eviction policy noeviction is the default by omission and is wrong for a cache: at the limit reads keep working while every write fails with an OOM error, so the cache stops accepting entries while looking healthy.

Persistence

Append-only file (AOF)

Off means RDB snapshots only, so a restart loses every write since the last one. Correct for a cache, data loss for anything else.

Network

No password is written into the output, deliberately. A generated credential outlives every rotation policy.

Bind address Binding to 0.0.0.0 with no password is remote code execution, not merely a data leak: CONFIG SET dir plus SAVE writes a file anywhere Redis can write.

Port

redis.conf

updates as you type

Examples

Worked setups you can load into the form above. Each one is a decision the generator makes differently, and the reason it makes it.

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

A cache that refuses writes

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.

role: cache
maxmemory-policy: noeviction
maxmemory: 2gb

A datastore with no AOF

Snapshots alone lose every write since the last one. That is correct for a cache and is data loss for anything else.

role: datastore
appendonly: no
maxmemory: 8gb

Common mistakes

These are the ones that fail silently. The config is accepted, nothing raises an error, and the consequence arrives later.

Setting maxmemory to the size of the machine
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.
Leaving maxmemory-policy at the default on a cache
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.
Putting requirepass in the file and committing it
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.
Assuming CONFIG SET changes survive a restart
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.

Four defaults that are not what you want

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.

maxmemory is unlimited by default

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.

noeviction is the default policy

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.

A datastore with no AOF loses writes on restart

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.

The memory limit is not the machine size

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.

What this cannot know

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.

Related redis tools

redis.conf to CONFIG SET Which of these can you change without a restart? Redis Maxmemory Config Generator The limit, and the headroom it needs Redis Persistence Config Generator How much you can afford to lose Redis TLS Config Generator Encrypted, and the old port actually closed Redis Sentinel Config Generator Failover that can actually be authorised Redis Cluster Config Generator Three primaries, and the bus port open

All 53 redis tools

Elsewhere on the site

Terraform Validator & Formatter Kubernetes YAML Generator Kubernetes YAML Validator AWS IAM Policy Validator & Analyzer