Redis is one of the fastest data stores on the planet: an in-memory key-value database that teams use as a cache, session store, message broker and rate limiter. Installing it on Ubuntu takes five minutes, but most tutorials stop right there — and an unprotected Redis server exposed to the internet is one of the most commonly exploited misconfigurations in production.
In this guide you will install Redis on Ubuntu 22.04 or 24.04 from the official repositories, get it running properly under systemd, and then lock it down: a strong password, localhost-only binding, protected mode, firewall rules and renamed dangerous commands. This is aimed at developers and sysadmins setting up their first production Redis, or anyone hardening an existing one.
Prerequisites
- A server or VM running Ubuntu 22.04 or 24.04 (a fresh install is ideal).
- A non-root user with sudo privileges.
- About 100 MB of free disk space; at least 1 GB of RAM recommended since Redis stores data in memory.
- Basic comfort with the terminal and a text editor like
nano.
Step 1 — Update the package index
Always refresh the package lists before installing anything, so you pull the latest Redis version available in your Ubuntu release.
sudo apt update && sudo apt upgrade -yapt update downloads the newest package metadata, and apt upgrade -y applies pending system updates without prompting. On a fresh server this takes a minute or two.
Step 2 — Install Redis
Install the redis-server package from Ubuntu's official repositories. On Ubuntu 24.04 this gives you Redis 7.x, which is current enough for production use.
sudo apt install redis-server -yThis installs the Redis server, the redis-cli command-line client, and a default configuration file at /etc/redis/redis.conf. Ubuntu also ships a systemd unit, so Redis can run as a managed service.
Step 3 — Configure Redis properly under systemd
Open the main configuration file. The stock config starts Redis in the foreground, which fights with systemd; switching to systemd supervision lets systemd manage restarts and logging cleanly.
sudo nano /etc/redis/redis.confFind the line that says supervised no and change it to:
supervised systemdThis tells Redis to signal systemd when it is ready and to hand over process supervision, so systemctl restart redis-server behaves correctly and the service can auto-restart on failure. Save and exit with Ctrl+X, then Y, then Enter.
Step 4 — Enable and start the service
Make Redis start on boot and start it now:
sudo systemctl enable redis-server
sudo systemctl start redis-serverenable creates the boot-time symlink; start launches the process immediately. Confirm it is running:
sudo systemctl status redis-serverYou should see active (running) in green. Press q to exit the status view.
Step 5 — Test the basic connection
Use the bundled client to ping the server:
redis-cli pingA healthy server answers with PONG. Let's also store and read a test key to prove reads and writes work:
redis-cli set mytestkey "Hello Redis"
redis-cli get mytestkeyThe second command should print "Hello Redis". Delete the test key to keep things clean:
redis-cli del mytestkeyStep 6 — Set a strong password
By default Redis has no password and trusts anyone who can reach port 6379. Fix that now by editing redis.conf again:
sudo nano /etc/redis/redis.confFind the commented line # requirepass foobared, uncomment it, and replace the password with a long random one:
requirepass YOUR_VERY_LONG_RANDOM_PASSWORD_HEREGenerate a good one with openssl rand -base64 32 and paste the output. requirepass makes every client authenticate before running any command — the single most important hardening step.
Step 7 — Bind Redis to localhost only
Unless application servers on other machines must reach Redis directly, it should listen only on the loopback interface. In the same config file, confirm these lines:
bind 127.0.0.1 ::1
protected-mode yesbind 127.0.0.1 ::1 restricts Redis to local connections on both IPv4 and IPv6 loopback. protected-mode yes (the default) makes Redis reject remote connections when no password is set — a safety net if you ever misconfigure the bind address.
Step 8 — Rename dangerous commands
Commands like FLUSHALL, FLUSHDB and CONFIG can wipe data or rewrite your config if an attacker ever gets authenticated access. Rename them to long random strings so they are effectively unguessable. Add these lines to redis.conf:
rename-command FLUSHDB 9f8d2c1a7e4b5a6c3d0f1e2a9b8c7d6e5f4a
rename-command FLUSHALL 7a1b2c3d4e5f60718293a4b5c6d7e8f9a0b1c
rename-command CONFIG 3c4d5e6f708192a3b4c5d6e7f8091a2b3c4d5Generate your own random values — do not copy these. After a rename, even an authenticated client typing FLUSHALL gets ERR unknown command.
Step 9 — Apply the config and verify authentication
Restart Redis so all the changes take effect:
sudo systemctl restart redis-serverNow an unauthenticated ping should fail, and the authenticated one should succeed:
redis-cli ping
redis-cli -a YOUR_VERY_LONG_RANDOM_PASSWORD_HERE pingThe first command returns (error) NOAUTH Authentication required. and the second returns PONG. That is exactly what you want. (Using -a on the command line exposes the password in shell history — for scripts, prefer AUTH password inside an interactive redis-cli session.)
Step 10 — Add a firewall rule (and block the port publicly)
Even bound to localhost, defense in depth is good practice. If your server runs UFW, deny Redis traffic from the outside world while allowing your own SSH:
sudo ufw allow ssh
sudo ufw deny 6379/tcp
sudo ufw enable
sudo ufw statusdeny 6379/tcp explicitly blocks Redis's default port at the firewall level, so even a config mistake cannot expose it. If an application server on another machine legitimately needs access, allow only its IP instead: sudo ufw allow from 10.0.0.5 to any port 6379.
Verify it worked
Run this end-to-end checklist to confirm a healthy, hardened install:
# 1. Service is running under systemd
sudo systemctl is-active redis-server
# 2. Listening only on localhost
sudo ss -tlnp | grep 6379
# 3. Unauthenticated access is rejected
redis-cli ping
# 4. Authenticated access works
redis-cli -a YOUR_PASSWORD ping
# 5. Dangerous commands are renamed
redis-cli -a YOUR_PASSWORD FLUSHALLYou should see active, a line showing 127.0.0.1:6379 (and ::1:6379), a NOAUTH error, PONG, and an unknown command error respectively. Check the Redis version while you are here: redis-cli -a YOUR_PASSWORD INFO server | grep redis_version.
Common issues & fixes
1. "Could not connect to Redis at 127.0.0.1:6379: Connection refused"
The server is not running. Check status with sudo systemctl status redis-server and start it with sudo systemctl start redis-server. If it fails to start, run sudo journalctl -u redis-server -n 50 — a typo in redis.conf (for example an invalid requirepass line) is the usual culprit.
2. "(error) NOAUTH Authentication required" on every command
This is not an error — it means your password is working. Authenticate first: run AUTH YOUR_PASSWORD inside redis-cli, or pass -a YOUR_PASSWORD. If you lost the password, stop Redis, comment out requirepass, restart, set a new one, and restart again.
3. "WRONGPASS invalid username-password pair" even with the right password
You may have special characters in the password that the shell is interpreting. Wrap the password in single quotes: redis-cli -a 'p@ss!word#'. Better still, avoid shell-special characters when generating passwords with openssl rand -base64 output you paste carefully, or use AUTH interactively.
4. Redis won't start after editing redis.conf: "Bad directive or wrong number of arguments"
A malformed line in the config — often a rename-command with a missing value or an accidental line wrap in nano. Restore from the backup Ubuntu keeps at /etc/redis/redis.conf package defaults by comparing with sudo apt install --reinstall redis-server only as a last resort (it can overwrite your config); safer is to re-edit the specific line flagged in journalctl.
5. Warning: "The TCP backlog setting of 511 cannot be enforced" and overcommit_memory warnings in the log
These are Linux kernel tuning hints, harmless on small setups but worth fixing on busy servers. Run echo 'net.core.somaxconn=65535' | sudo tee -a /etc/sysctl.conf && sudo sysctl -p for the backlog warning, and echo 'vm.overcommit_memory=1' | sudo tee -a /etc/sysctl.conf && sudo sysctl -p for the overcommit warning, then restart Redis.
Conclusion
You now have Redis installed on Ubuntu, running as a proper systemd service, protected by a strong password, bound to localhost, with dangerous commands renamed and the port firewalled. That is the baseline every production Redis should meet before it serves real traffic. From here, the natural next steps are enabling AOF persistence for durability, setting up replication for high availability, or putting Redis behind your application's private network.
Setting up caching layers, session stores or full server stacks and would rather not wrestle with configs? XpertBees handles Redis, database and server setup for teams of every size — reach out and we will get your infrastructure hardened and production-ready.
