Exposed with no password
The configuration behind essentially every public Redis compromise
bind 0.0.0.0 protected-mode no port 6379
Redis Production Config Linter
Paste a redis.conf and get the problems that cause real incidents, in severity order. Each finding says what breaks, not merely that a setting differs from a default.
Paste below, or drop a file anywhere on this panel
Or drop a file anywhere on this panel. Nothing is uploaded: the analysis runs in this tab.
The answer appears here
Paste on the left and press Lint. Nothing leaves this tab.
Formatted
Results
Nothing else to flag.
No formatting problems, and nothing the rules object to. Worth remembering what that covers: this reads the file you pasted, not the account or cluster it will be applied to.
No finding matches that filter.
Examples
Real input you can load into the tool above. Each one shows a different thing going wrong, because that is what the tool is for.
A cache that refuses writes
noeviction is the default, so this arrives by omission rather than by choice
requirepass hunter2 maxmemory 2gb
Persistence off
A restart loses everything, which is fine for a cache and not stated anywhere
requirepass hunter2 maxmemory 2gb maxmemory-policy allkeys-lru appendonly no save ""
Common mistakes
These are the ones that fail silently. The config is accepted, nothing raises an error, and the consequence arrives later.
Adding a bind line without setting a password
protected-mode only refuses outside connections while there is no password and no bind. Adding a bind removes that guard, and an unauthenticated Redis on a network is remote code execution, not just a data leak.
Instead:Set requirepass or ACL users before changing bind or protected-mode.
Running a cache on the default eviction policy
noeviction is the default and refuses writes at the limit while reads keep working. For a cache that is an outage arriving by omission.
Instead:allkeys-lru or allkeys-lfu for a cache. Keep noeviction only where the data must not be dropped.
Choosing a volatile- policy without TTLs on the keys
Those policies only evict keys that have a TTL. With no TTLs there is nothing eligible, so they behave exactly like noeviction and the failure looks like a broken policy.
Instead:Confirm keys actually get a TTL, or use the allkeys- variant.
The four failures worth checking before anything else
Redis ships with defaults chosen for a developer laptop, not for a server. Most production problems come from a small number of them being left alone.
An exposed instance with no password
protected-mode refuses outside connections while there is no password and no bind, which contains a default install. Adding a bind line or turning protected-mode off removes that guard, and an unauthenticated Redis reachable from a network is remote code execution rather than merely a data leak: CONFIG SET dir plus SAVE writes a file anywhere the process can write.
No maxmemory
With no limit Redis grows until the kernel's OOM killer terminates the process, losing everything not persisted. A limit turns that into either eviction or a clear OOM error to the client. Set it to roughly 60 to 70 percent of the host, because replication buffers, client output buffers and the fork that BGSAVE performs all live outside the limit.
noeviction on something used as a cache
noeviction is the default, and at the limit it refuses writes while reads keep working. For a datastore that is correct. For a cache it is an outage, and because it is the default it arrives by omission rather than by decision. The volatile- policies have a sharper version of the same trap: if no key has a TTL there is nothing eligible to evict, so they behave exactly like noeviction.
Persistence off by accident
appendonly defaults to no, and save "" disables snapshots. Together they mean a restart loses everything. That is a reasonable choice for a cache and a serious one for anything else, and the file should say which it is.
What this cannot see
It reads one file. It cannot see included files, command line arguments, runtime CONFIG SET changes, your network topology, or whether the port is actually reachable from anywhere dangerous. A clean result here means these particular rules found nothing, not that the deployment is safe.
Related redis tools
Redis ACL Validator Find the rule that does nothing redis.conf to CONFIG SET Which of these can you change without a restart? Redis Config File Generator A redis.conf with the reasons in it 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
All 53 redis tools