Anyone who has spent a late night chasing down a slow API endpoint knows the moment when the database query logs finally reveal the truth: the app is hammering MySQL or PostgreSQL for data that barely changes. That’s usually the point where Redis enters the conversation. It’s fast, it’s simple to reason about, and once it’s wired into a caching layer or session store, response times drop in a way that makes stakeholders notice.

Installing Redis on Fedora 44, though, isn’t quite the copy-paste exercise it used to be. Fedora made a significant architectural decision starting with Fedora 41: Redis was replaced by Valkey, the open-source fork created after Redis Inc. changed its licensing terms away from a purely open-source model. On Fedora 44, running sudo dnf install redis doesn’t actually install Redis anymore — it pulls in Valkey compatibility packages that mimic the Redis binaries and command-line tools. That’s a meaningful detail that a lot of quick tutorials gloss over, and it can bite you if your production stack depends on a specific Redis version, a Redis module, or licensing compliance tied to the genuine upstream project.

This guide walks through both paths: the fast, default-repo route using Valkey (which is what most people actually want and won’t notice a difference in daily use), and the more deliberate route of installing genuine upstream Redis via the Remi repository, for teams that specifically need Redis branding, Redis Enterprise compatibility, or a particular Redis release stream. Along the way, we’ll cover configuration, systemd service management, firewall rules, memory tuning, persistence strategies, and the troubleshooting steps that actually come up in production — not the sanitized “it just works” version you get from generic blog posts.

Fedora 44 shipped as GA on April 28, 2026, running kernel 6.19 at release (with the update train already moving to 7.0.x), GCC 16.1, and Python 3.14 as the system default. It’s a leading-edge release, which means package versions move fast — something worth keeping in mind if you’re pinning Redis or Valkey versions for compatibility with an existing application stack.

Understanding the Redis vs. Valkey Situation on Fedora

Before running a single command, it helps to understand why this matters. In early 2024, Redis Ltd. relicensed Redis under the Redis Source Available License (RSALv2) and later the SSPL, moving away from the permissive BSD license that had defined the project for over a decade. The Fedora Project, which has strict open-source licensing requirements for anything in its main repositories, responded by deprecating Redis and adopting Valkey — a community-driven fork maintained under the Linux Foundation, using the original BSD 3-Clause license.

Practically speaking, this means:

• The redis package name on Fedora 44 is essentially an alias that installs Valkey underneath, via the valkey-compat-redis package, so that redis-cli and redis-server commands still exist and behave like Redis for backward compatibility.
• Configuration file paths, systemd unit names, and command syntax are nearly identical to real Redis, since Valkey was forked directly from Redis 7.2.4 before the license change.
• If your organization needs actual upstream Redis (for licensing reasons, Redis Stack modules like RedisJSON or RediSearch, or strict version matching with a managed Redis service), you’ll need to add the Remi repository and pull genuine Redis packages instead.

For the vast majority of use cases — session caching, rate limiting, pub/sub messaging, job queues with Celery or Sidekiq, leaderboard scoring — Valkey is a drop-in replacement and nobody will notice the difference in production. If you’re building on Redis Streams or Redis modules that Valkey hasn’t caught up on yet, that’s when the Remi route becomes worth the extra ten minutes.

Method 1: Installing Redis (via Valkey) from the Default Fedora Repos

This is the fastest path and the one most sysadmins will actually use.

Step 1: Update the System

Never skip this. Fedora’s rolling update cadence means packages you installed even a week ago can already be behind, and dependency mismatches during a Redis/Valkey install are almost always traceable to a stale package cache.

sudo dnf upgrade --refresh -y

The --refresh flag forces DNF to re-sync repository metadata instead of trusting its local cache, which matters more on Fedora than on slower-moving distros like RHEL or Debian because upstream packages change so frequently.

Step 2: Install the Redis-Compatible Package

sudo dnf install redis -y

Behind the scenes, DNF resolves this to Valkey and its compatibility shim. If you’d rather be explicit about it — and honestly, for documentation purposes on a production server, being explicit is the better habit — install it directly:

sudo dnf install valkey valkey-compat-redis -y

This gives you the Valkey server binary, the valkey-cli tool, and the redis-cli/redis-server symlinks for anything in your stack that still calls those commands by name.

Step 3: Enable and Start the Service

sudo systemctl enable --now redis

On Fedora 44, this unit name still resolves correctly thanks to the compatibility layer, though under the hood it’s managing the Valkey daemon. You can confirm what’s actually running with:

systemctl status redis
ps aux | grep -E 'redis-server|valkey-server'

Step 4: Verify the Installation

redis-cli ping

A healthy instance responds with PONG. If you get “Connection refused,” the service either isn’t running or isn’t listening on the expected socket — more on that in the troubleshooting section below.

Check the installed version:

redis-cli info server | grep -E 'redis_version|redis_mode'

You’ll likely see version strings reflecting the Valkey codebase, sometimes reported as a Redis-compatible version number depending on the compat package’s reporting behavior.

Method 2: Installing Genuine Upstream Redis via the Remi Repository

If your project genuinely needs upstream Redis — say, you’re running Redis Stack modules, you’re matching an AWS ElastiCache or Redis Cloud version for testing parity, or your compliance team specifically flagged BSD-vs-SSPL licensing as a concern in the other direction — the Remi repository is the standard community-maintained source for current Redis builds on Fedora and RHEL-family systems.

Step 1: Add the Remi Repository

sudo dnf install https://rpms.remirepo.net/fedora/remi-release-$(rpm -E %fedora).rpm -y

Using $(rpm -E %fedora) instead of hardcoding “44” is a small habit worth building — it means the same command works unchanged the next time you provision a Fedora 45 or 46 box, and you won’t have stale documentation floating around your internal wiki.

Step 2: List Available Redis Module Streams

sudo dnf module list redis --enablerepo=remi

Remi typically maintains multiple parallel Redis version streams (7.2, 7.4, 8.x, etc.), which is genuinely useful when you’re supporting legacy applications that haven’t been tested against the latest major release.

Step 3: Enable Your Target Version

sudo dnf module enable redis:remi-8.6 -y

Swap 8.6 for whichever stream matches your requirements. If a module was previously enabled and you need to switch:

sudo dnf module reset redis -y
sudo dnf module enable redis:remi-7.4 -y

Step 4: Install and Start Redis

sudo dnf install redis -y
sudo systemctl enable --now redis

Because the module is now pointed at Remi’s packages instead of Fedora’s Valkey-backed alias, this pulls genuine, upstream Redis binaries built from the actual Redis source tree.

Configuring Redis for Production Use

Default configurations are fine for a laptop test but not for anything touching real traffic. The main config file lives at /etc/redis/redis.conf (or /etc/redis.conf on some Remi package layouts — check with redis-cli config get dir if you’re unsure which path is active).

Binding and Network Access

By default, Redis binds only to 127.0.0.1, which is correct behavior and shouldn’t be casually changed. If an application server on a separate host needs access:

bind 127.0.0.1 10.0.0.5
protected-mode yes
port 6379

Never bind Redis to 0.0.0.0 on a machine with a public IP unless it sits behind a firewall and VPN, and even then, think twice. Redis has no meaningful built-in access controls by default, and unauthenticated Redis instances exposed to the internet are a well-documented target for cryptomining botnets.

Requiring a Password

requirepass Your-Long-Random-Passphrase-Here

Generate something real, not “redis123”:

openssl rand -base64 32

After editing the config, restart the service and test authentication:

sudo systemctl restart redis
redis-cli -a 'Your-Long-Random-Passphrase-Here' ping

For Redis 6+ and Valkey, Access Control Lists (ACLs) let you go further than a single shared password — you can create scoped users with limited command access, which matters if multiple internal teams or microservices share one Redis instance:

redis-cli -a yourpassword ACL SETUSER appuser on >apppassword ~cache:* +get +set +del

That user can only touch keys prefixed with cache: and only run GET, SET, and DEL — a small step that limits blast radius if one service’s credentials leak.

Persistence: RDB vs. AOF

This is where a lot of teams get burned during an unexpected reboot or OOM kill. Redis offers two persistence strategies, and picking the wrong one for your workload is a classic mistake.

RDB (snapshotting) is lightweight and fast to restore but can lose several minutes of writes if the process dies between snapshots:

save 900 1
save 300 10
save 60 10000

AOF (append-only file) logs every write operation and rewrites/compacts periodically, offering much stronger durability at the cost of larger disk I/O and slightly slower restarts on large datasets:

appendonly yes
appendfsync everysec

For a session cache where losing a few minutes of data is a non-event, RDB alone is fine and keeps disk I/O low. For a job queue or anything acting as a source of truth even temporarily, enable AOF — the extra I/O overhead is a fair trade for not silently losing queued work during a crash.

Memory Management

Redis is an in-memory store, which means uncontrolled growth eventually triggers the Linux OOM killer, and that’s rarely a graceful failure mode.

maxmemory 2gb
maxmemory-policy allkeys-lru

allkeys-lru evicts the least recently used keys once the limit is hit — the right policy for a pure cache. If Redis is holding data you can’t afford to lose (like a queue), use noeviction instead and monitor memory proactively rather than letting Redis silently discard data.

Firewall and Network Security

If Redis needs to accept connections from other hosts (a common pattern in multi-tier architectures where the app servers and cache live on separate boxes), open the port deliberately rather than disabling firewalld altogether — a mistake seen more often than it should be on freshly provisioned servers.

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

Scope this to an internal zone or a specific source range using rich rules if firewalld supports zone segregation on your network:

sudo firewall-cmd --permanent --zone=internal --add-rich-rule='rule family="ipv4" source address="10.0.0.0/24" port protocol="tcp" port="6379" accept'
sudo firewall-cmd --reload

Pair this with SELinux, which Fedora enforces by default. If Redis needs to bind to a non-standard port or read config files from an unusual location, check the audit log before assuming a config error:

sudo ausearch -m avc -ts recent | grep redis

If SELinux is blocking something legitimate, generate a policy module rather than disabling enforcement wholesale:

sudo grep redis /var/log/audit/audit.log | audit2allow -M redis_custom
sudo semodule -i redis_custom.pp

Performance Tuning: The Details That Actually Matter

Disable Transparent Huge Pages

This one catches people out constantly. Transparent Huge Pages (THP) can cause latency spikes and fork() delays during RDB snapshotting, and Redis explicitly warns about it in its startup logs.

echo never | sudo tee /sys/kernel/mm/transparent_hugepage/enabled

Make it persistent across reboots with a systemd service or a line in /etc/rc.local, or better, a dedicated tuned profile if you’re already using tuned for other performance settings.

Adjust the overcommit_memory Kernel Parameter

Redis forks a child process to write RDB snapshots or rewrite AOF files. Under default memory overcommit settings, this fork can fail on systems under memory pressure even when there’s technically enough memory available, because the kernel assumes worst-case memory duplication.

echo 'vm.overcommit_memory = 1' | sudo tee -a /etc/sysctl.d/99-redis.conf
sudo sysctl -p /etc/sysctl.d/99-redis.conf

Increase the TCP Backlog

Under high concurrency — think a traffic spike from a marketing campaign or a flash sale — the default net.core.somaxconn value can cause connection drops before Redis even sees the request.

tcp-backlog 511

And match it at the kernel level:

echo 'net.core.somaxconn = 511' | sudo tee -a /etc/sysctl.d/99-redis.conf
sudo sysctl -p /etc/sysctl.d/99-redis.conf

Disk I/O Considerations

If AOF is enabled and Redis lives on the same volume as other write-heavy services, disk contention becomes a real bottleneck under load. Placing the Redis data directory on a dedicated NVMe volume, or at minimum a separate disk from your database’s write-ahead logs, avoids a scenario where two services fight over the same I/O queue during peak traffic.

Troubleshooting Common Redis Issues on Fedora

“Could not create server TCP listening socket” on startup. Almost always means another process already holds port 6379, or a previous Redis/Valkey process didn’t shut down cleanly. Check with sudo ss -tlnp | grep 6379 and kill the stale process before restarting the service.

Redis starts, but redis-cli ping from a remote host times out. Nine times out of ten this is either the bind directive still limiting connections to localhost, or firewalld blocking the port. Rule out one at a time — first confirm local connectivity works, then check firewall-cmd --list-all, then check the bind directive.

“NOAUTH Authentication required” errors from your application. The app’s connection string is missing the password, or requirepass was added after the app’s connection pool was already established. Restart the application after any Redis auth change — connection pools rarely pick up new credentials mid-flight.

High memory usage that doesn’t match expected dataset size. Check for key sprawl from an application bug (missing TTLs on cache keys is the classic culprit) using:

redis-cli --bigkeys
redis-cli info memory | grep used_memory_human

Set a default TTL policy in application code rather than relying on manual cleanup — cache keys without expiration are how a 500MB cache quietly becomes a 20GB memory hog over a few weeks.

Service fails after a Fedora system upgrade. Because Fedora ships fast-moving releases, upgrading from Fedora 43 to 44 can shift the underlying package from Remi’s Redis stream back to the default Valkey alias if the module enablement doesn’t survive the upgrade. Re-check dnf module list redis after any major version jump.

Fork failures during BGSAVE. This ties back to the overcommit_memory setting above — if you see “Can’t save in background: fork: Cannot allocate memory” in the logs, that sysctl change is the fix, not adding more RAM.

Best Practices Worth Adopting

Monitor Redis with something beyond redis-cli info run manually during incidents. Tools like redis_exporter for Prometheus, paired with Grafana dashboards, catch slow memory creep and connection pool exhaustion long before users notice latency. For a Streamlit-based internal dashboard setup, pulling INFO command output on a timer and charting used_memory, connected_clients, and instantaneous_ops_per_sec gives a lightweight real-time view without standing up a full monitoring stack.

Run redis-cli --latency periodically on production instances, especially after any config change — it’s a fast sanity check that catches regressions before they show up in application-level metrics.

Back up RDB snapshots off-host on a schedule, not just when someone remembers. A cron job pushing /var/lib/redis/dump.rdb to object storage nightly is a five-minute setup that saves a very bad day later.

Keep Redis or Valkey pinned to a specific module stream in production rather than letting dnf upgrade silently bump major versions. Test version upgrades in staging first — client library compatibility issues between major Redis versions are more common than people expect.