Redis Basics for Web Apps: Caching, Sessions and Queues on a VPS

Redis is an in-memory data store. It keeps data in RAM, which makes reads and writes extremely fast, and it supports simple but useful data types: strings, lists, sets, hashes and more. Web applications use it to remember things quickly so they do not have to recompute or re-query them. It is a staple of modern stacks, but it is also a service that has caused real breaches when left open to the internet, so the setup details matter.

What Redis is used for

• Caching. Store the result of an expensive database query or page fragment for a few minutes. WordPress object-cache plugins and frameworks such as Laravel and Django have Redis support.
• Sessions. Keep login sessions in a shared, fast store so several app servers can read them.
• Queues. Background job libraries use Redis lists or streams to hand work from the web process to workers, for example sending emails or resizing images.
• Counters and rate limiting. Atomic increment operations make it easy to count requests per visitor.
• Pub/sub. Lightweight messaging between processes.

Redis does not replace your main database. It is best thought of as a very fast helper beside it.

Install and try it

sudo apt install redis-server
redis-cli ping

A reply of PONG means it runs. Some distributions now package Valkey, a community fork that speaks the same protocol, so package and service names may differ slightly; the concepts and commands below apply equally. Try the basic commands:

redis-cli
127.0.0.1:6379> SET greeting "hello"
127.0.0.1:6379> GET greeting
127.0.0.1:6379> EXPIRE greeting 60
127.0.0.1:6379> TTL greeting
127.0.0.1:6379> INCR visits

EXPIRE gives a key a lifetime in seconds, after which Redis removes it automatically; this is the heart of caching. TTL shows the time left, and INCR adds one to a counter atomically.

Secure it before anything else

Redis was designed for trusted networks, so its default behaviour assumes nobody hostile can reach it. Follow these rules on a public server:

• Bind to localhost. Check bind 127.0.0.1 ::1 in /etc/redis/redis.conf and confirm with sudo ss -tlnp | grep 6379.
• Firewall port 6379. It should never be reachable from the internet. If another server needs access, allow only that address, or better, use a private network or an SSH tunnel.
• Require authentication. Set a long random password with requirepass, or define users with ACLs (supported in Redis 6 and later) to limit which commands each client may run.
• Do not run as root, and keep the package updated.

Attackers actively scan for open Redis servers because an unauthenticated instance can be abused to read data or even to write files on the host. Treat "Redis is reachable from outside" as an emergency.

Memory limits and eviction

Since everything lives in RAM, Redis needs a ceiling. Without one it can consume memory until the kernel kills processes. For a cache, set a limit and an eviction policy in redis.conf:

maxmemory 256mb
maxmemory-policy allkeys-lru

With allkeys-lru, when the limit is reached Redis removes the least recently used keys to make room, which is exactly what you want for a cache. If you use Redis for queues or data you cannot lose, you do not want silent eviction; pick a policy such as noeviction so writes fail loudly, and size the memory generously. Choose the number from your server's free memory after the database and application have taken their share. Restart with sudo systemctl restart redis-server after editing, or change it live with CONFIG SET.

Persistence: do you need it?

Redis can save its data to disk in two ways:

• RDB snapshots write the dataset at intervals. Compact and fast to restore, but changes since the last snapshot can be lost in a crash.
• AOF (append-only file) logs every write, giving finer durability at the cost of more disk activity.

A pure cache can lose its contents safely: the application just refills it. Sessions and queues usually deserve persistence, and you should include the data directory in your backups if the data matters. Remember that persistence is not a substitute for backups.

Connecting your application and watching it

Every major language has a client library. Use a connection setting from an environment variable, such as REDIS_URL=redis://:[email protected]:6379/0, and keep the password out of source control. Give different applications different database numbers or, better, key prefixes so they do not collide. In WordPress, an object-cache plugin that supports Redis can reduce database load on busy sites, though the benefit depends on the site's plugins and traffic, so measure before and after.

Watch it in operation

redis-cli INFO memory reports memory use, and redis-cli INFO stats shows hits and misses; a very low hit rate means your cache keys or lifetimes need rethinking. Avoid the KEYS * command on a busy server, as it blocks Redis while scanning everything; use SCAN instead.

If you are unsure whether you need Redis at all, start without it. Page caching and database indexes often give more benefit for less effort, and a CDN can take much of the load off the server. See the CDN page for that approach.

Redis on Zebra Hosting

Redis is a service you install and secure yourself, so it belongs on a server where you control the software, such as a Zebra Hosting VPS.