Installing and Configuring Valkey on Fedora Server: A Production-Ready Redis Alternative - ITFROMZERO - Share tobe shared! Need an urgent Redis replacement due to licensing changes? Learn how to deploy Valkey on Fedora Server, from installation and kernel tuning to network security and real-world benchmarking.

Table of Contents

Context: The 2 AM Redis Exodus

At 2:15 AM, the phone rang off the hook. It wasn’t a database crash alert, but an urgent email from the compliance team: all Redis clusters across staging and production had to be deprecated immediately due to Redis switching to the dual RSALv2/SSPL license. For a system serving over 40,000 concurrent users (CCU), solving an open-source compliance emergency in the dead of night was a true nightmare for our team.

Our most viable lifeline at that moment was Valkey. Backed by the Linux Foundation with sponsorship from AWS, Google Cloud, and Oracle, Valkey is driven by former veteran Redis core maintainers. Valkey retains the permissive BSD 3-Clause license and guarantees full API compatibility with Redis 7.2.4. Popular client libraries such as redis-py, ioredis, and predis connect seamlessly without requiring a single line of backend code to change.

Our team runs Fedora Server clusters for internal microservices. Fortunately, the Fedora project introduced Valkey into its official repositories starting with Fedora 40 to completely supersede legacy Redis packages. As a result, our migration went smoothly during the night shift without needing to compile from source.

Installing Valkey on Fedora Server

Once connected via SSH, installation is straightforward since the packages are available directly from the official repositories.

Inspect the available package information on your system:

sudo dnf info valkey

Install the Valkey server along with the backward-compatibility package:

sudo dnf install -y valkey valkey-compat-redis

The valkey-compat-redis package cleanly solves legacy scripting issues. It sets up symlinks pointing redis-cli to valkey-cli and redis-server to valkey-server. Existing cron jobs, deployment pipelines, and backup scripts continue to run seamlessly without needing any rewrites.

Hardening Configuration for Production

Never leave default settings untouched in a production environment. Out of the box, Valkey does not set a password and only listens on localhost. Open the primary configuration file to tune it:

sudo nano /etc/valkey/valkey.conf

1. Network Binding and Authentication

Restrict the service to listen only on your internal private IP (e.g., 10.0.0.15), never exposing it to the public Internet. At the same time, enforce a strong authentication password:

# Listen on localhost and application cluster private IP
bind 127.0.0.1 10.0.0.15

# Enable protected mode
protected-mode yes

# Standard port
port 6379

# Strong password with at least 32 random characters
requirepass vK9#mQ2$xL8!pZ4@wE7*rT1^yU5&iO3(

2. Memory Limits and Eviction Policies

Allowing Valkey to consume memory unchecked is the leading cause of processes being killed by the Linux OOM Killer. On a 16GB RAM server shared with other worker processes, allocate a dedicated, safe ceiling:

# Hard memory ceiling of 4GB for cache
maxmemory 4gb

# Automatically evict least recently used keys when memory limit is reached
maxmemory-policy allkeys-lru

3. Persistence Configuration

When handling user session caches, data must survive service restarts. Combine periodic RDB snapshots with the Append-Only File (AOF) engine:

# Enable AOF logging for all write operations
appendonly yes
appendfilename "appendonly.aof"

# Fsync to disk every second to prevent IOPS bottlenecks
appendfsync everysec

4. Kernel Tuning

When launching on Linux, Valkey typically logs warnings regarding virtual memory allocation and latency. The two most common culprits are an unconfigured vm.overcommit_memory setting and Transparent Huge Pages (THP), which can introduce latency spikes from 0.5ms up to dozens of milliseconds. Eliminate these issues by applying kernel parameters:

# Prevent process fork failures during RDB snapshotting
echo 'vm.overcommit_memory = 1' | sudo tee /etc/sysctl.d/99-valkey.conf
sudo sysctl --system

Disable Transparent Huge Pages using a systemd service that triggers on boot:

sudo nano /etc/systemd/system/disable-thp.service

Service configuration contents:

[Unit]
Description=Disable Transparent Huge Pages (THP) for Valkey
DefaultDependencies=no
After=sysinit.target local-fs.target
Before=valkey.service

[Service]
Type=oneshot
ExecStart=/bin/sh -c 'echo never > /sys/kernel/mm/transparent_hugepage/enabled && echo never > /sys/kernel/mm/transparent_hugepage/defrag'

[Install]
WantedBy=basic.target

Enable and start the service:

sudo systemctl daemon-reload
sudo systemctl enable --now disable-thp.service

5. Firewall Rules for Internal Subnets

Fedora Server enables firewalld by default. Restrict port 6379 access specifically to your application server subnet (e.g., 10.0.0.0/24) rather than opening it globally:

sudo firewall-cmd --permanent --zone=internal --add-source=10.0.0.0/24
sudo firewall-cmd --permanent --zone=internal --add-port=6379/tcp
sudo firewall-cmd --reload

Testing and Real-World Benchmarking

Start the Valkey service and enable it to launch automatically upon reboot:

sudo systemctl enable --now valkey
sudo systemctl status valkey

Once the service reports active (running), verify the connection directly using the CLI tool:

valkey-cli -a "vK9#mQ2$xL8!pZ4@wE7*rT1^yU5&iO3("

Execute standard test commands:

127.0.0.1:6379> PING
PONG
127.0.0.1:6379> SET auth_token:user_4892 "active_session" EX 3600
OK
127.0.0.1:6379> GET auth_token:user_4892
"active_session"
127.0.0.1:6379> TTL auth_token:user_4892
(integer) 3594

Monitoring Memory and Latency Metrics

Inspect memory allocation details with:

127.0.0.1:6379> INFO memory

Focus on three critical metrics:

used_memory_human: Actual memory consumed by dataset storage.
maxmemory_human: Configured memory ceiling (4GB in this example).
mem_fragmentation_ratio: Fragmentation ratio. The ideal range is between 1.0 and 1.3; values above 1.5 suggest high physical memory fragmentation.

Monitor real-time throughput under application load using continuous statistics mode:

valkey-cli -a "vK9#mQ2$xL8!pZ4@wE7*rT1^yU5&iO3(" --stat

This utility outputs per-second statistics: connected clients, total keys, memory footprint, and requests per second (RPS). When stress-tested with valkey-benchmark -q -n 100000 -c 50, our instance sustained roughly 92,000 RPS with a p99 latency under 0.8ms. Migrating from Redis to Valkey was completed swiftly and effectively, resolving our licensing compliance risks while keeping system performance flawless.