Use ACL rules. Create a named user for each application, remove the dangerous command category, and deny specific commands such as CONFIG and FLUSHALL. The older rename-command directive still exists, but the Redis documentation marks it deprecated and says it may be removed in future versions.
Why application users should not have every command
In a default Redis setup, clients get the full command set. Redis documentation notes that one FLUSHALL can delete the entire data set, and that CONFIG lets a client change the working directory and dump file name, which can lead to files written at paths you did not intend. A cache client that only needs GET, SET and EXPIRE has no reason to hold those powers.
The two methods compared
| ACL rules | rename-command | |
|---|---|---|
| Status | Recommended method since Redis 6 | Deprecated, may be removed |
| Granularity | Per user, per command, per subcommand (Redis 7.0 and later) | One global rename for every client |
| Auditing | Named users, so you know who did what | Everyone shares the same view |
| Admin access | Give admin tasks to a separate user | Admin must know the secret new name |
| Config location | redis.conf or an external ACL file | redis.conf |
Steps to restrict an application user
- Create a dedicated user. Generate its password with ACL GENPASS, which produces a 32-byte random value from the system's cryptographic generator.
- Start from the commands the app really needs. A user that only uses lists might get a few categories and a key pattern, like the Redis documentation's example of a worker limited to the list category and keys starting with jobs.
- If you prefer a deny list, begin with all commands and subtract the dangerous category, then add explicit denials for the commands you worry about.
- Check what a category contains on your own version with ACL CAT followed by the category name, for example dangerous.
- Load the rules, test with the application user, and confirm the denied commands fail.
An example rule set looks like this:
ACL SETUSER cacheapp on >replace-with-generated-password ~cache:* +@all -@dangerous -flushall -flushdb
Redis documentation uses the same pattern, +@all followed by -@dangerous. It also warns that module commands are not part of normal categories, so an additive rule like +@all can include module commands. An allow list is safer than a deny list for that reason.
Subcommands and the default user
From Redis 7.0 you can allow or block subcommands with a pipe, for example allowing config get while blocking config set. If you plan to keep one monitoring account, this lets it read settings without changing them.
Do not forget the default user. In a fresh install it is on, needs no password and can run everything. Lock it down or disable it once your named users work. See Redis ACL users: replace the default user nopass for the steps.
If you must keep rename-command
Older Redis versions without ACLs have no alternative. The documentation shows renaming CONFIG to an unguessable name, or to an empty string to disable it entirely. Plan a migration, because a deprecated directive can disappear in a future release and your configuration would then fail to behave as expected.
Safeguard's policies and gates can check configuration files in pull requests, and its asset discovery can help you find Redis instances nobody listed. Try the free scan on your repositories.
Quick check
Do key patterns stop a user from running FLUSHALL?
No. Redis documentation says commands that take no key arguments, including FLUSHALL, FLUSHDB and SWAPDB, are governed by command rules and not by key patterns. Deny them explicitly.
Is rename-command safe to keep for now?
It works today, but it is deprecated and may be removed. Treat it as a stopgap and move to ACL rules.
Sources
Last reviewed: 19 October 2026.
