Type sudo dnf install redis on Fedora 45 and you get Valkey 9.1, not Redis. The redis name now belongs to valkey-compat-redis, a small package of symlinks, so redis-cli, redis-server and redis.service all still work, and the server even reports redis_version:7.2.4 so that old client libraries stay happy. For caching, sessions and queues you won’t notice the swap. You will notice it the first time an app calls JSON.SET or FT.SEARCH, because those modules ship with Redis 8 and not with Fedora’s Valkey.
This guide installs Redis the Fedora way, fixes the memory warning it logs on first start, adds a password, opens it to remote clients, and sets up persistence and a memory limit. Then it runs real Redis 8 in Podman for the cases that need its modules, with a benchmark of the two on the same VM. Every step ran on Fedora 45 in October 2026, with the install and a remote client repeated on Fedora 44.
Install Redis on Fedora
Fedora dropped the Redis package after Redis moved to the non-open-source RSALv2 and SSPLv1 licences with 7.4, and replaced it with Valkey, the Linux Foundation fork of the last BSD-licensed Redis. Redis 8 has since added AGPLv3 as a third option, according to the Redis licensing page, but Fedora still ships Valkey. Our Valkey vs Redis comparison covers the fork in detail. Both Fedora releases carry it in the main repositories.
| Fedora 45 | Fedora 44 | |
|---|---|---|
| Valkey | 9.1.2 | 9.0.6 |
Package that provides redis | valkey-compat-redis | valkey-compat-redis |
| Config file | /etc/valkey/valkey.conf | /etc/valkey/valkey.conf |
| Extra modules packaged | valkey-module-knot only | valkey-module-knot only |
Install by either name. Asking for redis pulls in Valkey plus the compatibility package, which is the one to use if scripts or tools on the box call redis-cli by name:
sudo dnf install -y redisThe transaction shows what the name really maps to. This is the full list from Fedora 44; Fedora 45 installed the same four packages at 9.1.2, with valkey-rdma coming in as a weak dependency on both:
Installing:
valkey-compat-redis noarch 0:9.0.6-1.fc44 updates 1.5 KiB
Installing dependencies:
librdmacm x86_64 0:61.1^20260812git975bdaf-1.fc44 updates 153.9 KiB
valkey x86_64 0:9.0.6-1.fc44 updates 6.3 MiB
Installing weak dependencies:
valkey-rdma x86_64 0:9.0.6-1.fc44 updates 88.0 KiB
Transaction Summary:
Installing: 4 packagesYou can confirm with rpm -ql valkey-compat-redis that the compatibility package holds only symlinked names and one migration script.
/usr/bin/redis-benchmark
/usr/bin/redis-check-aof
/usr/bin/redis-check-rdb
/usr/bin/redis-cli
/usr/bin/redis-sentinel
/usr/bin/redis-server
/usr/lib/systemd/system/redis-sentinel.service
/usr/lib/systemd/system/redis.service
/usr/libexec/migrate_redis_to_valkey.shWatch the last file if you’re upgrading a box that ran Fedora’s old Redis package. The compat package runs it whenever it gets installed, and that includes a dnf system-upgrade from a Fedora release that still had the redis package, because valkey-compat-redis obsoletes redis older than 7.4. The script copies /etc/redis/redis.conf to /etc/valkey/valkey.conf, renames the original to .rpmsave, fixes the dir and logfile paths, and moves everything in /var/lib/redis into /var/lib/valkey. It is a one-way move, so back up /var/lib/redis before the release upgrade or before installing redis or valkey on such a box, and review the copied config afterwards, because the script only rewrites those two settings.
Start the service and check it
Enable the real unit, valkey.service. redis.service is only an alias to it, so systemctl restart redis works, but you’ll find the logs and drop-ins under the real name.
sudo systemctl enable --now valkey
ss -ltn | grep 6379Out of the package it listens on loopback only, IPv4 and IPv6, which is the safe default for an app on the same machine:
LISTEN 0 511 127.0.0.1:6379 0.0.0.0:*
LISTEN 0 511 [::1]:6379 [::]:*Ping it through the old name, then ask the server who it is.
redis-cli ping
valkey-cli INFO server | grep -E "redis_version|valkey_version|server_name|config_file|executable"Look at the two version lines. valkey_version is the real one; redis_version is frozen at 7.2.4, the last Redis that Valkey forked from, so libraries that check it for feature support keep working:
PONG
redis_version:7.2.4
server_name:valkey
valkey_version:9.1.2
executable:/usr/bin/valkey-server
config_file:/etc/valkey/valkey.confSELinux confines it as redis_t (ps -eZ | grep valkey shows it), and the policy already knows the default port and paths, so there’s nothing to relabel as long as you keep the data in /var/lib/valkey.
Above is the whole install on our Fedora 45 VM, from the transaction to the version check.
Fix the memory overcommit warning
On first start Valkey logs a warning to /var/log/valkey/valkey.log, not to the journal, so most people never see it. Fedora’s default vm.overcommit_memory is 0, and Valkey wants 1 because its background saves fork the whole process:
20261:M 15 Oct 2026 19:11:20.533 # WARNING Memory overcommit must be enabled! Without it, a background save or replication may fail under low memory condition. Being disabled, it can also cause failures without low memory condition, see https://github.com/jemalloc/jemalloc/issues/1328. To fix this issue add 'vm.overcommit_memory = 1' to /etc/sysctl.conf and then reboot or run the command 'sysctl vm.overcommit_memory=1' for this to take effect.Put the setting in its own file under /etc/sysctl.d rather than /etc/sysctl.conf, so it’s obvious later which service needed it, and load it without a reboot:
echo "vm.overcommit_memory = 1" | sudo tee /etc/sysctl.d/90-valkey.conf
sudo sysctl -p /etc/sysctl.d/90-valkey.conf
sudo systemctl restart valkeyAfter the restart the warning was gone from the log. The setting is system-wide, so it changes how the kernel treats memory requests from every process on the machine. On a box where Valkey shares memory with other heavy services, give it a maxmemory limit as well, which comes up below.
Require a password
Valkey accepts any local connection without a password. That is acceptable only when every process on the machine is trusted, so set one before anything else connects. The setting lives in the main config file:
sudo vim /etc/valkey/valkey.confFind the commented requirepass foobared line, around line 1240 in Fedora 45’s file, and replace it. Generate the value with openssl rand -hex 16 or similar:
requirepass use-a-long-random-passwordvalkey.conf is marked as a config file in the package, so a later dnf upgrade keeps your edits and drops the new default next to it as .rpmnew. Restart and test without the password first:
sudo systemctl restart valkey
valkey-cli pingAn unauthenticated client now gets this instead of PONG.
NOAUTH Authentication required.Pass the password through the environment rather than -a, which shows it in the process list. read -rs keeps it out of your shell history too. valkey-cli reads VALKEYCLI_AUTH, and because redis-cli is the same binary, it reads that variable as well; with only VALKEYCLI_AUTH exported, redis-cli ping answered PONG in our test:
read -rs VALKEYCLI_AUTH
export VALKEYCLI_AUTH
valkey-cli pingAllow remote clients
Keep Valkey on loopback if the app runs on the same machine. When app servers connect over the network, three things have to line up, and the password from the previous section is one of them:
bindset to an address the clients can reachrequirepassset, soprotected-modelets remote clients in- port 6379 open in firewalld, ideally only to the app subnet
In the same valkey.conf, the packaged bind 127.0.0.1 -::1 line becomes this, where the leading dash on the IPv6 entry tells Valkey not to fail if IPv6 is not available. Leave protected-mode yes as it is; with a password set it no longer blocks remote clients:
bind 0.0.0.0 -::*Binding to one interface address instead of 0.0.0.0 is tighter when the server has a separate private network. Restart Valkey, then open the port only to the machines that need it. firewalld already defines a redis service for 6379, and a rich rule limits it to a source range. Fedora Server runs firewalld by default. Our cloud image did not, so we installed and enabled it first with sudo dnf install -y firewalld and sudo systemctl enable --now firewalld; the default zone already allows SSH, so your session survives. Replace 10.0.1.0/24 with your app subnet:
sudo systemctl restart valkey
sudo firewall-cmd --permanent --add-rich-rule='rule family="ipv4" source address="10.0.1.0/24" service name="redis" accept'
sudo firewall-cmd --reloadWe tested the rule with a single /32 source: our Fedora 44 client reached Valkey and a workstation on the same LAN got no answer at all. The rule covers IPv4 only, which is fine here because clients reach the server over IPv4; add a matching family="ipv6" rule if yours use IPv6. sudo firewall-cmd --permanent --add-service=redis is the blunt alternative, opening 6379 to everything the zone covers. From the Fedora 44 client, the server at 10.0.1.50 refused a connection without the password and answered one with it. The literal password below is for illustration; use read -rs on real clients too:
valkey-cli -h 10.0.1.50 ping
VALKEYCLI_AUTH='use-a-long-random-password' valkey-cli -h 10.0.1.50 INFO server | grep -E 'valkey_version|redis_version'You get NOAUTH from the first command, and the second reports the server’s versions even though the client itself is Fedora 44’s 9.0 build.
NOAUTH Authentication required.
redis_version:7.2.4
valkey_version:9.1.2Your password crosses the network in plain text. Across anything you don’t control, keep Valkey on a private network or behind a VPN. Once it serves real traffic, our guide to monitoring Valkey with Prometheus and Grafana works the same against this install.
Here is the remote test from the Fedora 44 client, run against the Fedora 45 server after the firewall change.
Turn on persistence and a memory limit
Out of the package, Valkey keeps data in memory and writes RDB snapshots at the built-in save points, with the append-only file off. CONFIG GET save showed the defaults.
save
3600 1 300 100 60 10000
appendonly
noRead that as: snapshot after an hour if one key changed, after five minutes if 100 changed, after a minute if 10,000 changed. A crash loses everything since the last snapshot, which is fine for a cache and not for a job queue or session store. For those, switch on the append-only file (AOF), which logs every write and syncs it once a second (appendfsync everysec, the default), so a crash costs about a second of writes.
Switch to AOF without losing data
Don’t do it by changing appendonly no to yes in valkey.conf and restarting. We loaded 4,986 keys, saved them to dump.rdb, made exactly that edit and restarted: DBSIZE came back as 0. Valkey starts from the append-only file when AOF is on, finds none, creates a new empty one and ignores the RDB snapshot sitting next to it. The Valkey persistence docs warn about this; the next snapshot then overwrites dump.rdb with the empty dataset, so the loss becomes permanent unless you copied the file. Turn AOF on at runtime instead, so Valkey writes the file from the data in memory first. Back up the snapshot, then flip the setting:
sudo cp -a /var/lib/valkey/dump.rdb /var/lib/valkey/dump.rdb.bak
valkey-cli CONFIG SET appendonly yes
valkey-cli INFO persistence | grep -E "^aof_enabled|aof_rewrite_in_progress|aof_rewrite_scheduled|aof_last_bgrewrite_status"Wait until the rewrite has finished, which on our ten thousand keys took less than the three seconds we waited:
aof_enabled:1
aof_rewrite_in_progress:0
aof_rewrite_scheduled:0
aof_last_bgrewrite_status:okNow make it permanent by changing the same line in the file by hand, so the next restart keeps AOF on. Avoid valkey-cli CONFIG REWRITE here. On our box it also appended a user default on #<hash> line built from the current password, and that line wins over requirepass at startup: when we later changed requirepass and restarted, the new password got WRONGPASS and the old one still worked. The hand edit leaves the file as you wrote it:
sudo sed -i 's/^appendonly no/appendonly yes/' /etc/valkey/valkey.conf
sudo systemctl restart valkey
valkey-cli DBSIZE
valkey-cli INFO persistence | grep -E "^aof_enabled|aof_last_write_status"All 9,959 keys from before the switch came back after the restart, now loaded from the append-only file. Copy dump.rdb.bak off the server once you’ve confirmed that, because a backup on the same disk doesn’t survive the disk:
9959
aof_enabled:1
aof_last_write_status:okError: “OOM command not allowed when used memory > ‘maxmemory'”
Set a memory ceiling with maxmemory 512mb in valkey.conf, sized below the RAM you can spare, because AOF rewrites and snapshots fork the process and need headroom on top of it. maxmemory on its own does not make Valkey a cache, though. The default maxmemory-policy is noeviction, so once used memory passes the limit, writes are refused instead of old keys making room. We set a 2 MB limit at runtime, and the 50 connections of valkey-benchmark pushed memory past it before the first write landed:
Error from server: OOM command not allowed when used memory > 'maxmemory'.Refusing writes is the right behaviour for a queue or session store, where silently dropping data is worse than a loud error. For a pure cache, add maxmemory-policy allkeys-lru as well. With a 20 MB limit and that policy, we wrote 60,000 values of 1 KB on top of the roughly 5,000 keys already there: Valkey evicted 48,249 keys, kept 16,643 and held used memory at 18.22 MB under the limit.
Run Redis 8 when you need its modules
Redis 8 folds JSON, Search, TimeSeries, Bloom filters and vector sets into the server itself. Fedora packages none of those for Valkey, so an app built on them fails against the packaged server. We ran the official image in Podman on the same Fedora 45 VM to compare. Our Podman on Fedora guide covers the rootless setup, and a Quadlet unit is how you would keep such a container running as a service.
sudo dnf install -y podman
podman run -d --name redis8 -p 127.0.0.1:6380:6379 docker.io/library/redis:8
env -u VALKEYCLI_AUTH valkey-cli -p 6380 INFO server | grep redis_versionThe env -u keeps the Valkey password you exported earlier away from the container, which has none. With the variable set, every command to port 6380 also printed AUTH failed: ERR AUTH <password> called without any password configured for the default user. The image was on Redis 8.10.2, and MODULE LIST named search, ReJSON, timeseries, bf and vectorset. The same JSON command against each server shows the difference in one line each:
env -u VALKEYCLI_AUTH valkey-cli -p 6380 JSON.SET doc $ "{\"a\":1}"
valkey-cli JSON.SET doc $ "{\"a\":1}"Redis 8 on port 6380 answered OK. Valkey on 6379 didn’t know the command.
ERR unknown command 'JSON.SET', with args beginning with: 'doc' '$' '{"a":1}' Both answers side by side on the Fedora 45 box, with the Redis 8 version line first:
Speed is not a reason to pick one. We ran valkey-benchmark three times against each, SET and GET with 50 clients and 200,000 requests, with Redis on host networking so both used the same path. Valkey kept its default snapshot points during the run and Redis had saving off, which if anything favoured Redis:
| Run | Valkey 9.1.2 SET / GET (req/s) | Redis 8.10.2 SET / GET (req/s) |
|---|---|---|
| 1 | 186,220 / 183,655 | 185,701 / 178,094 |
| 2 | 185,185 / 180,180 | 188,501 / 184,162 |
| 3 | 184,162 / 181,488 | 188,679 / 175,593 |
Spread between runs is as large as the gap between servers, and on a 2-vCPU VM the benchmark client competes with the server for CPU, so this measures the box more than either engine. Our call: use the packaged Valkey for caching, sessions, rate limits and queues, where it is a drop-in with distro updates and SELinux confinement. On Rocky Linux the packaged choice is the same, as our Valkey on Rocky Linux guide shows. Run Redis 8 in a container only when the app needs the built-in modules. Run it as a rootful Quadlet unit, or as a rootless one with loginctl enable-linger for that user, because our rootless test container showed Exited (0) once the login session that started it was gone. Check the AGPLv3 terms if you modify it and offer it as a network service.
