How To Install and Configure Redis for Caching on Ubuntu
Tricknowtech Team 7 min read
Goal
In this tutorial, you will install Redis on Ubuntu, configure it to run under proper systemd supervision, confirm it's bound to localhost by default, secure it with a password as defense in depth, verify each step, and understand the basic cache-aside pattern applications use with it.
Prerequisites
An Ubuntu 22.04 or 24.04 LTS server with a non-root user that has sudo privileges
Basic familiarity with the command line and a text editor such as nano
A firewall (ufw or similar) already set up, especially if you plan to expose Redis to a separate app server in Step 8
Let an AI agent do this for you
Copy a ready-made prompt for an AI coding assistant with terminal access to your server (Claude Code, Cursor, or similar) — it can carry out the steps below for you. Review what it plans to run before it executes anything.
Redis is an in-memory data store commonly used to cache expensive database queries, session data, and computed results so an application can serve repeat requests without hitting its primary database every time. This tutorial covers a full, safe default installation on Ubuntu: getting Redis running under proper systemd supervision, keeping it bound to localhost unless you explicitly need otherwise, adding a password even for local-only access, and verifying each step actually took effect.
Step 1 — Install Redis
Redis is available directly from Ubuntu's repositories, which is the simplest and most reliably up-to-date path for both 22.04 and 24.04 LTS.
The package's post-install scripts create a redis system user, write a default configuration to /etc/redis/redis.conf, and enable + start the redis-server systemd service automatically. You don't need to enable it manually.
Step 2 — Enable systemd supervision
Open the config file in an editor:
bash
sudo nano /etc/redis/redis.conf
Find the supervised directive. By default it's set to no:
ini
supervised no
Change it to:
ini
supervised systemd
This matters because with supervised no, systemd has no way to know when Redis has actually finished starting up or is ready to shut down cleanly — it just launches the process and assumes it's running. With supervised systemd, Redis calls sd_notify to tell systemd exactly when it's ready and when it's stopping, which the shipped Ubuntu unit file is already written to expect (Type=notify). Without this, you can end up with systemd issuing a hard kill during a restart or reboot before Redis has finished flushing its snapshot to disk.
Step 3 — Confirm Redis is bound to localhost only
While still in redis.conf, check the bind directive. The Ubuntu package ships it already set correctly:
ini
bind 127.0.0.1 -::1
This restricts Redis to accepting connections only from the same machine, over both IPv4 and IPv6 loopback. Redis has no authentication enabled by default out of the box, so this bind setting is the primary thing keeping it from being reachable by anyone else on the network. Leave it as-is if your application server and Redis run on the same host — which is the common case for a caching layer. If you need Redis reachable from a separate app server, don't touch this yet; that's covered as an explicit, deliberate step later, not a default to change casually.
Tricknowtech VPS Hosting
Dedicated KVM resources and full root access — deployed in under 60 seconds, no ticket required.
Save and close the file (in nano: Ctrl+O, Enter, Ctrl+X).
Step 4 — Restart Redis and confirm it's running
bash
sudo systemctl restart redis-server
sudo systemctl status redis-server
You should see active (running) and, on recent Ubuntu releases, Loaded: loaded (...; enabled; ...). Press q to exit the status pager if it opens one. With no password configured yet, a bare ping should also succeed:
bash
redis-cli ping
text
PONG
That confirms Redis is up and accepting local connections before you add authentication in the next step — useful for isolating whether a later problem is the service itself or the password you're about to set.
Step 5 — Set a password with requirepass
Even though Redis is only reachable from localhost right now, add a password. This is defense in depth: any other process, script, or compromised application running on the same box could otherwise connect to Redis with zero credentials and read or overwrite everything in it. Generate a strong random value first:
bash
openssl rand -base64 32
Copy the output — you'll paste it into the config file below, and you'll also store it in a shell variable so the rest of this tutorial's commands work by copy-paste instead of you having to retype the password into every one of them. Run this in the same shell you'll use for the remaining steps (it only lasts for that shell session):
bash
REDIS_PW='paste-the-value-openssl-printed-here'
Now edit the config again:
bash
sudo nano /etc/redis/redis.conf
Find the commented-out requirepass line and set it to the same value you just put in REDIS_PW — a config file can't read a shell variable, so this one has to be typed or pasted in literally:
ini
requirepass REPLACE_WITH_YOUR_GENERATED_PASSWORD
“This password grants full read and write access to every key stored in this Redis instance — treat it exactly like a database password. Never commit it to source control or paste it into a shared chat. Make sure the requirepass line holds your actual generated value, not the placeholder text shown above.”
Save and close the file (in nano: Ctrl+O, Enter, Ctrl+X). Then restrict who can even read the config file, since it now contains a plaintext credential:
bash
sudo chmod 600 /etc/redis/redis.conf
Restart Redis so the new setting takes effect:
bash
sudo systemctl restart redis-server
Step 6 — Verify the password is enforced
Confirm Redis now requires the password, using the REDIS_PW variable you set in Step 5:
bash
redis-cli -a "$REDIS_PW" ping
A working setup replies:
text
PONG
“Passing -a on the command line works, but the password briefly ends up in your shell history and in the process list (visible to other users via `ps` while the command runs). For scripts, or if that bothers you interactively, set the REDISCLI_AUTH environment variable instead — redis-cli picks it up automatically without the password appearing in the command itself:”
bash
export REDISCLI_AUTH="$REDIS_PW"
redis-cli ping
Step 7 — The caching pattern in practice
Applications talk to Redis through a client library for their language (redis-py for Python, ioredis or node-redis for Node.js, phpredis or Predis for PHP, Jedis or Lettuce for Java, and so on), connecting with the host, port 6379, and the password you set. The common cache-aside pattern is: check Redis for the key first; on a miss, compute the value or query the primary database, then store it in Redis with an expiration so it doesn't go stale forever. SETEX sets a key with a time-to-live in seconds in one call — here, 3600 seconds (1 hour):
bash
redis-cli SETEX example_key 3600 "example_value"
redis-cli GET example_key
When the TTL expires, Redis removes the key automatically — the application doesn't need a separate cleanup process to keep the cache from growing unbounded with stale entries.
Step 8 — If Redis needs to be reachable from a separate app server
If your application runs on a different host than Redis, loopback binding won't work, and this needs two changes made together, not one alone. First, bind Redis to the address that the app server can actually reach (in addition to keeping loopback for local tools):
ini
bind 127.0.0.1 -::1 203.0.113.10
Replace 203.0.113.10 with the Redis server's own real address on your network. Second, and just as important, restrict inbound access at the firewall to only the specific application server's IP address — for example, 198.51.100.20:
bash
sudo ufw allow from 198.51.100.20 to any port 6379 proto tcp
Never bind Redis to 0.0.0.0 and rely on requirepass alone to protect it. Unauthenticated or weakly-authenticated Redis instances reachable from the open internet are routinely scanned for and abused within minutes — this is one of the most common real-world server compromise vectors, not a theoretical risk. The bind address and the firewall rule together, scoped to one known source IP, keep the exposure to the minimum needed. Restart after editing:
bash
sudo systemctl restart redis-server
Step 9 — A note on persistence
Redis keeps its dataset in memory, but by default it also periodically writes point-in-time RDB snapshots to disk (/var/lib/redis/dump.rdb) based on the save rules already present in redis.conf — for example, saving if a certain number of keys changed within a given number of seconds. For a pure cache, where a cold start can simply repopulate from the primary database, this default is usually fine. If you need stronger durability guarantees, Redis also supports append-only file (AOF) logging (appendonly yes). Don't guess at fsync policy or rewrite thresholds for AOF — consult Redis's own persistence documentation for the current tuning guidance before enabling it in production, since those settings trade off durability against write performance.
Troubleshooting: "NOAUTH Authentication required"
Once requirepass is set, any client — redis-cli included — that connects without supplying the password gets:
text
(error) NOAUTH Authentication required.
This is expected behavior, not a bug: every connection now needs the password, including your own ad hoc redis-cli calls and any application client. Fix it by passing -a / setting REDISCLI_AUTH for redis-cli, or by adding the password to your application's Redis connection configuration (most client libraries accept it as a `password` field alongside host and port).
