Use case · In-memory data store

Self-hosted Redis on a dedicated server: memory, persistence, lockdown

Self-hosted Redis needs one thing above all: enough RAM for the dataset, plus headroom for the copy a background save can make, on a box where port 6379 never faces the internet. A dedicated server gives it all the memory, the disks for RDB and AOF files, and root to set the two kernel parameters the Redis docs ask for. The same steps apply to Valkey, the BSD-licensed fork.

See the machines

Memory decides the machine

Redis keeps the whole dataset in memory and uses disk only for persistence. The Redis FAQ says CPU is rarely the bottleneck: an instance is usually bound by memory or network. So start the sizing from RAM, then disks, then cores.

Footprint figures from the FAQ, on 64-bit builds; check your own keys with INFO memory:

What is storedMemory, per the Redis FAQ
An empty instanceabout 3 MB
1 million small string keys and valuesabout 85 MB
1 million hashes of 5 fields eachabout 160 MB

Two rules from the administration guide set the headroom. First, maxmemory must leave room for Redis overhead and fragmentation: the guide's example is 8 or 9 GB on a host with 10 GB free. Second, while it writes an RDB file or rewrites the AOF, a write-heavy instance can use up to 2 times its normal memory. The extra is proportional to the memory pages that writes modify while the save runs.

Our arithmetic from those two rules: on a 32 GB machine that persists a write-heavy dataset, a maxmemory near 12 GB leaves room for a full copy during a save plus the operating system. A cache with persistence off can sit much closer to the guide's 8-of-10 example.

Cache, queue or session store: three configurations

The policy names and their behaviour come from the Redis eviction reference; the pairing with each job is our recommendation.

Jobmaxmemory-policyPersistenceWhy
Cacheallkeys-lruOff, or RDB for warm restartsThe docs call allkeys-lru a good default when a subset of keys is hot. A lost key is a cache miss.
Job queuenoevictionAOF everysec plus RDBAn evicted job is a lost job. With noeviction a full instance refuses writes instead of dropping data.
Session storenoeviction, or volatile-lru if logouts are acceptableAOF everysec plus RDBSessions carry TTLs. volatile-* policies only evict keys with an expiry and behave like noeviction when none have one.

By default maxmemory is 0, meaning no limit, and the policy is noeviction. If you set maxmemory for a cache but leave the policy at its default, Redis starts refusing writes once the limit is reached instead of evicting keys.

Licences: Redis 7.2, 7.4 to 7.8, 8 and Valkey

The licence follows the version, per the Redis licences page:

  • Redis 7.2.x and earlier: BSD-3-Clause.
  • Redis Community Edition 7.4.x to 7.8.x: RSALv2 or SSPLv1, the dual source-available licence Redis announced on 20 March 2024. Redis states that neither is an open source licence.
  • Redis 8 and later (Redis Open Source): your choice of RSALv2, SSPLv1 or AGPLv3. AGPLv3 is OSI-approved.
  • Valkey: BSD 3-Clause, a project of the Linux Foundation. Its history page describes it as a fork of the open-source Redis.

Neither charges a licence fee; what changes is the licence text you accept. Redis states RSALv2's limits as two: you may not commercialise the software or provide it to others as a managed service, and you may not remove or obscure its licence notices. SSPLv1 sets conditions on offering the software as a service. Read the licence texts against your own case, with a lawyer if you are anywhere near selling Redis itself; a hosting page is not legal advice.

Setting it up on Ubuntu or Debian

  1. Turn the firewall on before anything else, SSH only. Confirm the ufw defaults file says IPV6=yes, or the rules guard IPv4 alone.
  2. Add the packages.redis.io repository and install Redis, exactly as the Redis install page gives it. For Valkey, the Valkey install page gives sudo apt update and sudo apt install valkey on Debian-based systems, and sudo apt install valkey-redis-compat on Ubuntu for redis-cli and other redis-* symlinks.
  3. Set vm.overcommit_memory = 1 and turn off transparent huge pages. The administration guide asks for both: the first stops background saves failing on fork(), the second removes a latency and memory penalty after fork.
  4. Generate a password with openssl rand -hex 32, paste it into the config file, set the memory limit and policy, then restart and confirm Redis listens on loopback only.
grep IPV6 /etc/default/ufw    # expect IPV6=yes
sudo ufw default deny incoming
sudo ufw allow 22/tcp
sudo ufw enable

sudo apt-get install lsb-release curl gpg
curl -fsSL https://packages.redis.io/gpg | sudo gpg --dearmor -o /usr/share/keyrings/redis-archive-keyring.gpg
sudo chmod 644 /usr/share/keyrings/redis-archive-keyring.gpg
echo "deb [signed-by=/usr/share/keyrings/redis-archive-keyring.gpg] https://packages.redis.io/deb $(lsb_release -cs) main" | sudo tee /etc/apt/sources.list.d/redis.list
sudo apt-get update
sudo apt-get install redis

echo 'vm.overcommit_memory = 1' | sudo tee -a /etc/sysctl.conf
sudo sysctl vm.overcommit_memory=1
echo never | sudo tee /sys/kernel/mm/transparent_hugepage/enabled

The transparent huge pages switch lasts until the next reboot; make it permanent the way your distribution prefers. The guide also asks for swap equal to the amount of RAM, so a runaway instance shows latency spikes rather than being killed by the OOM killer.

# /etc/redis/redis.conf - edit with: sudoedit /etc/redis/redis.conf
# This is the cache row of the table above.
bind 127.0.0.1 -::1
protected-mode yes
requirepass REPLACE_WITH_64_HEX_CHARS
# 12gb leaves save headroom on a 32 GB machine (see the sizing above)
maxmemory 12gb
maxmemory-policy allkeys-lru
appendonly no
# queue or sessions instead: maxmemory-policy noeviction,
# appendonly yes and appendfsync everysec

# then, from the shell
sudo chown redis:redis /etc/redis/redis.conf
sudo chmod 640 /etc/redis/redis.conf
sudo systemctl restart redis-server
sudo ss -ltnp | grep 6379       # only 127.0.0.1 and [::1]
redis-cli --askpass ping        # type the password, expect PONG

Those paths belong to the Redis package. Valkey's package uses its own config file, its own service and valkey-cli: find them with systemctl list-units | grep -i valkey and set the same lines there.

Why loopback, a password and a firewall

The Redis security page is blunt: Redis is designed for trusted clients in trusted environments, and anyone who reaches the port can run a single FLUSHALL and delete the dataset. Three fences, plus a safety net:

  • bind. The shipped redis.conf already sets bind 127.0.0.1 -::1. Keep it, or add a private address only. Never bind * on a public interface.
  • protected-mode yes. Keep it on as a safety net: if the password is ever removed, Redis again answers only loopback and Unix-socket clients.
  • A password or ACLs. requirepass sets the default user's password; ACL users (the docs' example: user worker +@list +@connection ~jobs:* on >ffa9203c493aa99) are the recommended method since Redis 6. Both live in clear text in the config file, which is why it is mode 640 and owned by the redis user. Do not pass the password with redis-cli -a: command-line arguments show in ps and shell history. Use --askpass or the REDISCLI_AUTH variable.
  • ufw with IPv6. Default deny incoming, SSH allowed, 6379 never opened to the world.

If an application on a second machine must connect, allow only that machine's address to 6379 with a ufw allow proto tcp from rule and turn on Redis TLS: the security page notes that AUTH travels unencrypted.

Persistence and backups

RDB writes point-in-time snapshots; by default Redis saves after an hour with one change, five minutes with 100, or a minute with 10,000. It is compact and restarts fast, but a crash loses the writes since the last snapshot. AOF logs every write; with the default appendfsync everysec you lose at most about a second. The persistence page recommends both together for safety comparable to PostgreSQL, and discourages AOF alone.

Backups are easy because an RDB file is never modified once written: Redis renames the finished snapshot into place atomically, so copying it while the server runs is safe. The docs suggest hourly copies kept for 48 hours, daily copies for a month or two, and one copy a day moved off the machine. AOF writes reach the disk every second, and the latency guide lists disk I/O as a cause of slow replies, so look at the NVMe dedicated servers when the write rate is high.

Which of our machines fit

Every line on the dedicated server range is a whole machine with root and no other tenant. Match the class to the dataset:

  • Moonshot cartridges, 8 to 64 GB on most lines. One small cache or session store per machine. The Xeon D-1587 cartridge takes up to 128 GB with a 1.92 TB NVMe drive for AOF.
  • Single and dual socket, up to 1 TB. A large cache, or Redis beside the application and its database on one box.
  • Quad socket, up to 2 TB. A dataset that must stay in one machine's memory; see four-socket servers.

Racked single-, dual- and quad-socket servers carry an out-of-band console (iLO, iDRAC or a Supermicro BMC), so a ufw rule that locks out SSH is recoverable without a ticket; cartridges other than the m510 and m710x have power control only. A racked machine is handed over in about 30 minutes once payment is approved. For a memory size or disk layout that is not on the shelf, build it to order in 4 to 24 hours. If Redis sits in front of a database, the PostgreSQL sizing notes cover the other half of the box.

When one machine is the wrong answer

A dataset larger than the RAM you can buy means sharding across instances; Redis keeps no on-disk backend. High availability means replicas and Sentinel or Cluster on more than one server, and the administration guide warns that a primary with persistence off must not restart automatically: it comes back empty and the replicas copy the empty set.

Questions

Is self-hosted Redis free to use?

Neither project charges a licence fee; what changes is the licence text you accept. Redis 8 and later come under your choice of AGPLv3, RSALv2 or SSPLv1, and Redis states that RSALv2 bars commercialising Redis or providing it to others as a managed service. Valkey is BSD 3-Clause. Read the texts against your own plans.

How much RAM should a Redis server have?

Enough for the dataset, Redis overhead and fragmentation, plus up to the same again during a save on a write-heavy instance. Set maxmemory below physical RAM: the Redis guide's example is 8 or 9 GB when 10 GB is free. Measure your own keys with INFO memory before you buy.

Will Redis use all the cores of a big server?

Not from one instance. The Redis FAQ says CPU is rarely the limit, and that to use more cores you run several instances on the same box and treat them as separate servers. Size for memory first.

Can I switch from Redis to Valkey later?

Valkey's documentation covers the same directives used here: bind, protected-mode, requirepass, ACLs, maxmemory, RDB and AOF. On Ubuntu, the valkey-redis-compat package symlinks the redis-* tool names. Test your client library and data files on a copy first.

Should the Redis port be open so my web servers can reach it?

Not to the internet. Open 6379 only to the addresses of your application servers, keep a password or ACL users on, and use TLS, because AUTH is sent unencrypted. Putting the application on the same machine and connecting over loopback avoids the question.

Put Redis on its own machine

Choose a line by memory first and disk second. Root access, a port nobody meters, one tenant.

See the machines

Related on Server Room

Other use cases