Introduction

Redis is an in-memory key-value store used for caching, session storage, pub/sub, and real-time data. In this tutorial you install Redis on Ubuntu, confirm it works with a quick test, then lock it down: bind to localhost only, require a password, and rename or disable dangerous commands so a mistake or an attacker can’t wipe or reconfigure your instance.

The guide works on Ubuntu 22.04 and later LTS releases. When you’re ready, log in to your Ubuntu server as your sudo user and continue below.

Key Takeaways

Install Redis from Ubuntu repositories and set supervised systemd in redis.conf for proper systemd process management.

Bind Redis to 127.0.0.1 ::1 to restrict access to the local machine and prevent internet exposure.

Configure a strong requirepass (or use ACLs in Redis 6+) in redis.conf to require client authentication.

Rename or disable potentially dangerous commands like FLUSHALL, CONFIG, and SHUTDOWN to minimize risk from accidents or attacks.

After each change, verify Redis is running and accessible using redis-cli ping, key tests, and systemctl status redis.

Prerequisites

Before you begin, ensure you have:

An Ubuntu server (any currently supported release).

A non-root user with sudo privileges.

A basic firewall, such as UFW, enabled and configured.

If you haven’t set this up yet, follow the Initial Server Setup guide for Ubuntu (works for Ubuntu 22.04 LTS and later). Once complete, log in as your non-root user to continue.

Why Secure Redis?

Redis assumes trusted clients on a trusted network. It has no authentication or access control by default. If port 6379 is reachable from the internet, anyone can connect and run any command: wipe all data with FLUSHALL, change config with CONFIG SET, or (in older setups) abuse CONFIG SET dir and dbfilename to write files to disk and potentially gain shell access. Binding to localhost, setting a password, and renaming dangerous commands limits who can connect and what they can do. The official Redis security docs go deeper.

Step 1 - Installing and Configuring Redis

Run these two commands to install Redis from the Ubuntu repositories (you get security updates via apt). Then set supervised systemd in /etc/redis/redis.conf so systemd manages Redis and can restart it if it crashes.

				
					
sudo apt update

sudo apt install redis-server

				
					
sudo nano /etc/redis/redis.conf

Search for supervised (e.g. Ctrl+W in nano). It’s usually under the GENERAL section. Change supervised no to supervised systemd. That’s the only change needed for this step.

				
					
. . .



# If you run Redis from upstart or systemd, Redis can interact with your

# supervision tree. Options:

# supervised no - no supervision interaction

# supervised upstart - signal upstart by putting Redis into SIGSTOP mode

# supervised systemd - signal systemd by writing READY=1 to $NOTIFY_SOCKET

# supervised auto - detect upstart or systemd method based on

# UPSTART_JOB or NOTIFY_SOCKET environment variables

supervised systemd



. . .

Save and close the file, then restart Redis so the change takes effect:

				
					
sudo systemctl restart redis.service

Check that Redis is running: sudo systemctl status redis. You should see Active: active (running). Then test with the CLI below.

Step 2 - Testing Redis

You should see Redis running and enabled. If not, enable it so it starts on boot. Then confirm the server responds with ping and that you can set and get a key.

				
					
sudo systemctl status redis

You should see Active: active (running). If it is not enabled to start on boot, enable it with:

				
					
sudo systemctl enable redis

				
					
● redis-server.service - Advanced key-value store

 Loaded: loaded (/lib/systemd/system/redis-server.service; enabled; vendor preset: enabled)

 Active: active (running) since Wed 2018-06-27 18:48:52 UTC; 12s ago

 Docs: http://redis.io/documentation,

 man:redis-server(1)

 Process: 2421 ExecStop=/bin/kill -s TERM $MAINPID (code=exited, status=0/SUCCESS)

 Process: 2424 ExecStart=/usr/bin/redis-server /etc/redis/redis.conf (code=exited, status=0/SUCCESS)

 Main PID: 2445 (redis-server)

 Tasks: 4 (limit: 4704)

 CGroup: /system.slice/redis-server.service

 └─2445 /usr/bin/redis-server 127.0.0.1:6379

. . .

Redis is running and enabled, so it will start on boot.

Note: This setting is desirable for many common use cases of Redis. If, however, you prefer to start up Redis manually every time your server boots, you can configure this with the following command:

				
					
sudo systemctl disable redis

Test connectivity with the Redis CLI:

				
					
redis-cli

In the Redis prompt, run:

				
					
ping

You should see PONG if the server is responsive.

				
					
PONG

Next, set a key:

				
					
set test "It's working!"

OK

Retrieve the value:

				
					
get test

You should see the value you stored:

				
					
"It's working!"

Exit the Redis prompt:

				
					
exit

To confirm persistence survives a restart, restart Redis and read the key again:

				
					
sudo systemctl restart redis

redis-cli get test

You should still see "It's working!". If so, the installation is working. Proceed to lock down access.

Step 3 - Binding to Localhost

Restrict Redis to localhost so only this machine can connect. Edit /etc/redis/redis.conf, ensure the line bind 127.0.0.1 ::1 is present and not commented out (no # at the start). If you see bind 0.0.0.0 or no bind line, replace or add bind 127.0.0.1 ::1.

				
					
sudo nano /etc/redis/redis.conf

Search for bind. You want exactly this line (no # in front):

				
					
bind 127.0.0.1 ::1

Save and close, then restart Redis:

				
					
sudo systemctl restart redis

Verify that Redis is listening only on loopback. Using ss (standard on Ubuntu):

				
					
ss -tlnp | grep 6379

				
					
LISTEN 0 128 127.0.0.1:6379 0.0.0.0:* users:(("redis-server",pid=…))

LISTEN 0 128 [::1]:6379 [::]:* users:(("redis-server",pid=…))

If you see 0.0.0.0:6379 instead of 127.0.0.1:6379, the bind didn’t apply; recheck the file and restart. Next, require a password so only clients that send AUTH can run commands.

Step 4 - Configuring a Redis Password

Set a password in /etc/redis/redis.conf with requirepass so only authenticated clients can run commands. (Redis 6+ also has ACLs for per-user permissions; for one shared password, requirepass is fine.)

Optional but recommended: back up the config before editing (sudo cp /etc/redis/redis.conf /etc/redis/redis.conf.bak). Then open the file:

				
					
sudo nano /etc/redis/redis.conf

Search for requirepass (often under a block titled SECURITY). You’ll see a commented line like # requirepass foobared. Remove the # and replace foobared with a strong password. For example:

				
					
requirepass your_secure_password_here

Note: Redis is very fast, so an attacker can try many passwords per second. Use a long, random password. You can generate one with:

				
					
openssl rand 60 | openssl base64 -A

On some systems -A may not be available; if the command fails, use openssl rand 60 | base64 (you may need to remove line breaks from the output before pasting into redis.conf). Example output (use as the value for requirepass):

				
					
RBOJ9cCNoGCKhlEBwQLHri1g+atWgn4Xn4HwNUbtzoVxAYxkiYBi7aufl4MILv1nxBqR4L6NNzI0X6cE

Save and close the file, then restart Redis:

				
					
sudo systemctl restart redis.service

Test that unauthenticated commands are rejected and that authentication works:

				
					
redis-cli

				
					
set key1 10

				
					
(error) NOAUTH Authentication required.

				
					
auth your_redis_password

OK

				
					
set key1 10

get key1

				
					
OK

"10"

				
					
quit

From the shell you can also pass the password once: redis-cli -a your_redis_password (the password may appear in process lists; for scripts, prefer AUTH inside the session or environment variables). Next, we restrict dangerous commands.

Step 5 - Renaming or Disabling Dangerous Commands

Rename or disable dangerous commands in /etc/redis/redis.conf so they can’t be run by mistake or by an attacker. Add rename-command lines in the SECURITY section: use an empty string to disable a command, or a hard-to-guess name to rename it.

[warning]

Warning: The rename-command approach is no longer the recommended way to secure commands in Redis 6+; use ACL rules for new deployments. The rename-command directive remains supported and effective for existing setups. Choose only the commands that make sense to disable or rename for your use case. Full command reference: redis.io/commands.

Open /etc/redis/redis.conf and scroll to the SECURITY section (or search for rename-command). Add these lines to the config file (they are redis.conf directives, not Redis CLI commands). To disable a command, set the new name to an empty string:

				
					
rename-command FLUSHDB ""

rename-command FLUSHALL ""

rename-command DEBUG ""

To rename a command to something only you know (hard to guess, easy for you to remember):

				
					
rename-command SHUTDOWN SHUTDOWN_MENOT

rename-command CONFIG ASC12_CONFIG

Save and close, then restart Redis:

				
					
sudo systemctl restart redis.service

Verify: after connecting and authenticating, the old command name should fail and the new one should work:

				
					
redis-cli

				
					
auth your_redis_password

config get requirepass

				
					
(error) ERR unknown command 'config'

				
					
asc12_config get requirepass

				
					
1) "requirepass"

2) "your_redis_password"

				
					
exit

[warning]

Warning: If you use AOF persistence or replication, renamed commands are stored and replicated under their new names. Apply the same renames (or ACLs) on all replicas and after restoring from AOF, or replay may fail. See the Redis security documentation and the project’s note on renaming and replication.

*The Redis project uses the terms “master” and “replica” in documentation; we use the same here for consistency with Redis.*

Redis Memory and Persistence Basics

Redis keeps data in memory. Two mechanisms help durability:

RDB (snapshots): Redis writes periodic point-in-time snapshots to disk as dump.rdb. Control frequency in redis.conf with save directives. Good for backups; you can lose data written since the last snapshot if the server crashes.

AOF (append-only file): Redis logs every write to a file and replays it on restart. Stronger durability than RDB; files are larger and replay can be slower. Enable with appendonly yes in the APPEND ONLY MODE section of redis.conf; tune rewrite and fsync for your needs.

Defaults on Ubuntu typically enable RDB; AOF can be enabled in the redis.conf section APPEND ONLY MODE with appendonly yes. For production, set maxmemory and a maxmemory-policy (e.g. volatile-lru) so Redis does not grow without bound and evicts keys when the limit is reached. See Redis persistence and Redis memory management for details.

Troubleshooting Common Issues

Redis won’t start after config changes

Run sudo redis-server /etc/redis/redis.conf (or add --daemonize no to see errors in the terminal) and read the error message. Often it’s a typo: e.g. requirepas instead of requirepass, or a space inside the password in the config.

Check sudo journalctl -u redis.service -n 50 for systemd messages.

If you broke the config, restore from backup: sudo cp /etc/redis/redis.conf.bak /etc/redis/redis.conf (if you made a backup earlier), then restart.

"NOAUTH Authentication required"

You set requirepass but the client did not send AUTH. Use redis-cli then auth your_password, or redis-cli -a your_password (with the usual caveats about process visibility).

"Connection refused" from another host

Redis is bound to 127.0.0.1 ::1, so it only accepts local connections. For remote access you need a secure design: e.g. SSH tunnel, VPN, or a dedicated app server that talks to Redis and never exposes the port publicly. Do not bind to 0.0.0.0 without a firewall and strong authentication.

Renamed command not found after restart

Confirm the rename-command lines are in the active redis.conf and that you restarted the service. If you use replicas or AOF, ensure all nodes use the same renames.

Firewall

If you ever bind Redis to a non-loopback address, restrict port 6379 with UFW or iptables so only trusted IPs can connect. See UFW essentials and Set up a firewall with UFW on Ubuntu.

Benefits and Trade-offs

Benefits

Reliable installation and updates via apt: Installing Redis from Ubuntu’s official repositories ensures you receive timely security patches and seamless integration with system tools. This reduces the risk of running outdated or vulnerable Redis versions.

Systemd supervision for high availability: Configuring supervised systemd in redis.conf enables systemd to monitor the Redis process and automatically restart it after crashes or failures, minimizing downtime and manual intervention.

Localhost binding significantly reduces attack surface: By binding Redis only to 127.0.0.1 and ::1, you ensure that only local processes can connect. This is a critical security measure that prevents remote exploits and is recommended for single-server deployments or where Redis is used as a local cache, session store, or queue.

Strong access control with authentication or ACLs: Enabling requirepass in the configuration requires clients to authenticate before running commands. On Redis 6+, Access Control Lists (ACLs) allow for granular, per-user permissions, essential for multi-tenant or production environments.

Mitigation of risky operations via command renaming: Disabling or renaming sensitive commands such as FLUSHALL, CONFIG, and SHUTDOWN helps prevent accidental data loss, unauthorized reconfiguration, and certain classes of attacks. This hardening step is especially important if your Redis instance is accessible by multiple applications or users.

Ideal for local caching, sessions, and job queues: This security-focused setup is best suited for workloads where Redis is accessed only from the same server, such as Laravel or Django sessions, Rails caching, or background job systems like Sidekiq or Celery, ensuring both performance and safety.

Trade-offs

No encryption for data in transit by default: Redis communication is plaintext unless explicitly configured with TLS. Sensitive data transmitted over networks without encryption is vulnerable to interception. For secure remote access, use TLS, a VPN, or SSH tunnels, and never expose Redis directly to the public internet.

Single shared secret in older Redis versions: The requirepass directive only provides a single global password. For environments requiring multiple users or roles, Redis 6+ ACLs are necessary to define user-specific credentials and permissions.

Shell access bypasses Redis-level security: Anyone with shell access to the server can read redis.conf and obtain the Redis password, bypassing authentication controls. Therefore, overall server hardening (SSH key authentication, firewall configuration, regular patching, and least-privilege principles) remains essential for true security.

Frequently Asked Questions

Should Redis be exposed to the public internet?

No. Redis assumes trusted clients. Bind to localhost (or a private IP) and put a firewall in front. Use SSH tunnels, a VPN, or an application proxy if remote access is needed.

How do I reset a Redis password?

Edit /etc/redis/redis.conf, change requirepass to the new value, save, and run sudo systemctl restart redis. Then use AUTH new_password in clients.

What port does Redis use?

Default is 6379/TCP. You can change it with the port directive in redis.conf.

How do I enable Redis persistence?

RDB is often enabled by default. For AOF, set appendonly yes in the APPEND ONLY MODE section of /etc/redis/redis.conf and restart Redis. See Redis persistence.

What is Redis protected mode?

When Redis is bound to all interfaces and has no password, protected mode (Redis 3.2+) makes it accept only connections from 127.0.0.1 and reject others with an error. It is a safety net; you should still set bind 127.0.0.1 ::1 and use requirepass or ACLs.

Is this guide valid for all supported Ubuntu versions?

Yes. The steps, package name (redis-server), configuration file path (/etc/redis/redis.conf), and systemd service name are consistent across all current Ubuntu LTS and non-LTS releases. Minor differences (such as command output details) may appear, but the installation and securing process remains the same.

How do I connect my application to Redis?

From the same server, use host 127.0.0.1 and port 6379. If you set a password, send AUTH your_password after connecting (or use your client’s password option). From another host, don’t expose Redis directly; use an SSH tunnel, a VPN, or an app on the Redis server that proxies requests. See your app’s docs (e.g. Laravel, Django, Node) for the exact connection format.

Conclusion

You’ve installed Redis on Ubuntu, confirmed it with ping and set/get tests, bound it to localhost, set a strong password, and optionally renamed or disabled dangerous commands. Redis is in a good state for local caching and development.

Redis’s own security (bind, password, renamed commands) only helps as long as the server itself is locked down. If someone can log in to the machine, they can read redis.conf and connect to Redis. So keep SSH and the firewall tight, apply updates, and never expose port 6379 to the internet. For managed Redis with backups and high availability, see managed databases for Redis. If you haven’t set up a firewall yet, use the Initial Server Setup guide for your Ubuntu version.

How To Install and Secure Redis on Ubuntu

Table of Contents