Installing Redis on Your Server: Persistence and Everyday Uses

Redis is an in-memory key-value store: fast, with rich data structures, and a natural fit for caching, sessions, queues, and counters. This guide walks through installing and using it on your own server or VPS with Ubuntu/Debian, and spells out the security step that trips people up most often.

Installation

The simplest route is your distribution's package manager:

sudo apt update
sudo apt install redis-server

Redis then runs as a systemd service. The commands you'll reach for:

sudo systemctl enable --now redis-server   # start now and on every boot
sudo systemctl status redis-server         # check it's healthy

Verify connectivity with the bundled client, redis-cli:

redis-cli ping        # PONG means you're good
redis-cli set foo bar
redis-cli get foo     # returns "bar"

Everyday uses

• Caching: stash database query results or rendered fragments in Redis and set a TTL with EXPIRE to take load off your backend.
• Sessions: keep login sessions in Redis so multiple app servers can share them and nothing is lost on restart.
• Queues: pair LPUSH with BRPOP for a simple task queue that drives async work.
• Counters and rate limiting: INCR is atomic, which makes it ideal for page-view tallies, like counts, and throttling requests.

Persistence: RDB vs AOF

Redis holds data in memory, so if the process dies, the data goes with it. That's what persistence is for. There are two mechanisms, and you can use either or both.

RDB (snapshots)

Redis dumps the whole dataset to a compact binary file (dump.rdb by default) at set intervals. Snapshots are small and restore quickly, but a crash between them loses whatever changed in the meantime. The defaults look like:

save 900 1      # snapshot if at least 1 write in 900 seconds
save 300 10
save 60 10000

AOF (append-only file)

Redis appends every write command to a log and replays it on restart. This is safer — you can fsync once per second — but the file grows larger and restarts are slower:

appendonly yes
appendfsync everysec

Rule of thumb: for a cache where losing a few seconds of data is fine, RDB is enough. When you treat Redis as something closer to a database of record, enable AOF, or run both together.

The security step you cannot skip

This is the part that actually matters. Huge numbers of unprotected Redis instances have been scanned and compromised over the years — an attacker who reaches a passwordless, internet-facing Redis can write malicious keys, tamper with your data, and often plant a crontab entry or SSH key to take over the whole box. So:

1. Bind to localhost

Edit /etc/redis/redis.conf and confirm Redis listens only on the loopback interface:

bind 127.0.0.1 -::1

Now only apps on the same host can connect. If you genuinely need remote access, go through a private network address or an SSH tunnel — never listen on 0.0.0.0.

2. Require a password

requirepass your-long-random-password

Clients then authenticate: redis-cli -a 'your-password'.

3. Keep protected mode on and firewall the port

Leave protected-mode yes (the default), then block port 6379 at the firewall:

sudo ufw deny 6379

Restart to apply your changes:

sudo systemctl restart redis-server

Summary

On Ubuntu/Debian, apt install redis-server gets you running, and redis-cli confirms it works; Redis shines for caching, sessions, queues, and counters. Choose persistence to fit the job: RDB for speed, AOF (or both) when data integrity counts. And whatever you do, bind 127.0.0.1 + requirepass + a firewall on 6379 is the non-negotiable baseline — a Redis left open to the internet will eventually be breached. Setting up those three defenses should be the very first thing you do.