Hardening Redis and Valkey

Redis is designed to be reached only by trusted clients on a trusted network. Its own documentation is blunt about this: it is “usually not a good idea to expose the Redis instance directly to the internet.” The daemon has no meaningful defence against an attacker who can open a socket to it, and an unauthenticated instance is not merely a data leak — it is a reliable path to running code as the Redis user.

Almost all of the work here is deciding who can reach the port and what they are allowed to run once they do.

7 controls

Bind Redis to a private interfaceA listener on 0.0.0.0 is reachable from anywhere routableSeverity: critical
Require authentication with Redis ACL usersAn unauthenticated instance accepts every command from anyone who connectsSeverity: critical
Restrict dangerous Redis commands with ACLsOne command can erase the dataset or write files as the Redis userSeverity: high
Enable TLS for RedisAUTH credentials and every value cross the network in plaintextSeverity: high
Leave Redis protected-mode onDisabling the last-resort guard on an otherwise open instanceSeverity: medium
Run Redis as an unprivileged userAs root, a file write from CONFIG SET becomes a root compromiseSeverity: medium
Secure the Redis config and data filesAny local user can read the password and the entire datasetSeverity: medium

First: are you running Redis or Valkey?

This matters before anything else on this page, because you may not have what you think you have.

Redis changed licence in 2024, and since Redis 8.0 it ships under a tri-licence (AGPLv3, SSPLv1 or RSALv2). Debian, Ubuntu and Fedora cannot ship source-available software in their main repositories, and moved toward Valkey — a BSD-licensed fork of Redis OSS 7.2.4, now maintained under the Linux Foundation. So on a current Ubuntu or Debian host, “installing Redis” may well have given you Valkey.

Find out rather than assume:

redis-cli INFO server | grep -iE 'redis_version|valkey_version|server_name'
# or, if the redis-cli binary isn't there:
valkey-cli INFO server | grep -iE 'version|server_name'

Everything in this cluster applies to both. Valkey accepts Redis-style configuration and supports the Redis 7.2 directives, so the settings are the same. Two things differ:

	Redis	Valkey
Config file	`/etc/redis/redis.conf`	`/etc/valkey/valkey.conf`
CLI	`redis-cli`	`valkey-cli`
Service / user	`redis-server`, `redis`	`valkey-server`, `valkey`

Where a page below says redis.conf and redis-cli, substitute the Valkey path and binary if that is what you are running. Nothing else changes.

Where the config lives

One file, no drop-in directory by default — unlike sshd, there is no conf.d precedence trap to worry about. But there is a different one:

CONFIG SET changes the running server without touching the file. A setting you changed at runtime is lost on restart, and a setting in the file may not be what the server is currently using. This is why every control here verifies with CONFIG GET against the running instance rather than by reading the file — and why CONFIG REWRITE exists to persist runtime changes back.

Before you start

Redis has no lockout risk in the SSH sense — you are not authenticating interactively, and a mistake doesn’t strand you on the host. The risk here is different and worth stating plainly: these changes break applications.

Binding to an interface, requiring a password, or restricting commands will cut off any client that isn’t expecting it. Have the connection strings ready to update, and prefer a maintenance window over a live change.