What does maxmemory-policy actually change?

It controls what Redis does once maxmemory is reached. noeviction returns errors on writes instead of evicting anything. The *-lru and *-lfu policies evict based on recency or frequency of access. The allkeys-* variants can evict any key, while volatile-* variants only evict keys that have an expiry set, leaving keys without a TTL untouched.

Should I use RDB or AOF persistence?

RDB takes periodic point-in-time snapshots (controlled by save rules like 'save 900 1'), which is compact and fast to restore from but can lose the last few minutes of writes on a crash. AOF logs every write operation and replays it on restart, offering much better durability at the cost of a larger file and slightly slower writes. Many production setups enable both, though this generator models them as an either/or toggle for simplicity.

What does the generated ACL user line actually do?

Each line follows Redis's ACL syntax: 'user on >password ' creates an enabled user with that password (the > prefix tells Redis to hash the plaintext that follows) and the given key/command/channel permissions, for example '~* &* +@all' grants access to all keys, all pub/sub channels, and all commands.

Is requirepass still relevant if I'm defining ACL users?

requirepass sets a password for the default user, which is separate from any named ACL users you define. Many setups disable or lock down the default user and rely entirely on named ACL users instead, but requirepass remains the quickest way to add a single shared password for simple deployments.

Redis Config Generator - redis.conf, Eviction & ACLs

Overview

Introduction

A production-ready redis.conf usually needs a handful of decisions made deliberately rather than left at defaults: what happens when maxmemory is hit, whether to trade durability for speed with RDB or AOF, and which named users are allowed to connect and with what permissions.

This tool turns those decisions into a form, generating a redis.conf with the right maxmemory-policy syntax, the correct save rules or appendonly setting for your chosen persistence mode, and one ACL user line per user you define.

What Is Redis Config Generator?

A generator for redis.conf covering bind/port, an optional requirepass, maxmemory paired with one of Redis's eight maxmemory-policy values, a persistence mode toggle between RDB snapshotting and AOF logging, and a repeatable list of ACL users.

Each ACL user is defined by a name, an optional password, and a permissions string, rendered as a single Redis ACL line in the 'user <name> on >password <permissions>' format.

How Redis Config Generator Works

bind, port, requirepass, and maxmemory map directly to their redis.conf directives; maxmemory-policy is chosen from a fixed set of eight valid values so the emitted policy name always matches what Redis's config parser accepts.

The persistence toggle emits either three save rules (900/1, 300/10, 60/10000) with appendonly no for RDB mode, or appendonly yes with appendfsync everysec for AOF mode, never a mix of both. Each ACL user row becomes one user line, defaulting to a broad '~* &* +@all' permission string when left blank and using 'nopass' when no password is given.

When To Use Redis Config Generator

Use it when standing up a new Redis instance and you want memory limits, eviction behavior, and persistence decided explicitly rather than left at Redis's defaults.

It's also useful for generating a starting set of ACL user lines for an application that needs scoped, named credentials instead of sharing the default user's password.

Features

Advantages

Always emits a valid maxmemory-policy value from the exact eight Redis supports, preventing a typo'd policy name from silently falling back to the default.
Generates internally consistent persistence settings, RDB save rules and AOF settings are never mixed in a way that contradicts the chosen mode.
Produces syntactically correct ACL lines, including the > password-hashing prefix and nopass fallback, without needing to memorize Redis's ACL rule syntax.

Limitations

Models persistence as a single either/or toggle; Redis itself allows enabling both RDB and AOF simultaneously for layered durability, which this tool doesn't represent.
Doesn't validate that ACL permission strings use valid category or command names, it passes through whatever permissions text you provide.
Doesn't cover Redis Cluster or Sentinel configuration, only a single standalone redis.conf.

Examples

An instance with LRU eviction, AOF persistence, and one scoped ACL user

Input

bind: 127.0.0.1, port: 6379, maxmemory: 512mb, policy: allkeys-lru, persistence: AOF; ACL user: app-cache, password: s3cret, permissions: ~cache:* +get +set

Output

bind 127.0.0.1
port 6379

# Memory management
maxmemory 512mb
maxmemory-policy allkeys-lru

# Persistence
appendonly yes
appendfsync everysec

# ACL users
user app-cache on >s3cret ~cache:* +get +set

The ACL line grants app-cache access only to keys under the cache: prefix with get and set commands, rather than the broad default permission string.

Best Practices & Notes

Best Practices

Pick an eviction policy that matches your key TTL strategy: use volatile-* policies if only some keys have expiries you want evicted first, allkeys-* if the whole keyspace is disposable cache data.
Enable AOF (or AOF+RDB in a real deployment) for any dataset where losing the last few minutes of writes on a crash is unacceptable.
Define narrowly scoped ACL users per application instead of sharing one broad-permission password across every client.

Developer Notes

Output is plain redis.conf text; maxmemory-policy is constrained to a literal union type of the eight valid Redis values so an invalid policy can't be emitted, and the persistence toggle branches to produce either RDB save rules or AOF settings, never both, keeping the output internally consistent with the selected mode.

Redis Config Generator Use Cases

Bootstrapping redis.conf for a new cache or primary data-store instance
Defining maxmemory and eviction behavior explicitly before a deployment instead of relying on Redis's defaults
Generating scoped ACL user lines for multiple applications sharing one Redis instance

Common Mistakes

Leaving maxmemory unset (or at 0) on a cache workload, which lets Redis grow unbounded until the host runs out of memory.
Choosing noeviction for a pure cache use case, which causes writes to start failing once memory fills instead of evicting old data.
Granting every ACL user the default '~* &* +@all' permissions instead of scoping each one to only the keys and commands it actually needs.

Tips

Use volatile-lru or volatile-ttl if you want Redis to evict expiring keys first while leaving keys without a TTL untouched.
Set an explicit maxmemory value any time Redis is sharing a host with other processes, so it can't consume memory those processes need.

Redis Config Generator