Describe the solution you would like
Add a valkey role (and an accompanying repo_valkey role if a dedicated repo
is needed) to install and configure Valkey as a drop-in alternative to Redis.
Decide and document a per-platform default for the key-value store used by LFOps
playbooks.
Why this needs to be addressed
The driver differs per platform, which is exactly why a single Valkey path is
worth having:
-
RHEL 10: forced. No redis package exists at all; the redis role loses
its first-party base and falls back to third-party sources (Remi module
streams or redis.io). Valkey from the AppStream is the only supported,
module-free path.
-
Debian / Ubuntu: license- and consistency-driven. Redis stays available,
but the 2024 relicense and the per-release license churn (BSD -> SSPL ->
AGPLv3) make a stable, BSD-licensed default attractive. Debian 13 and Ubuntu
24.04 already ship Valkey, so LFOps can offer it without third-party repos.
-
One product across the fleet. Without a Valkey role, RHEL 10 hosts drift
onto a different key-value store (or a third-party Redis) than the Debian /
RHEL 9 hosts. A Valkey role lets us standardise on one Redis-compatible store
across all supported platforms, reducing the support matrix.
-
Security updates and support. Distro-shipped Valkey (AppStream / Debian /
Ubuntu) gets vendor security backports on the distro cadence; a third-party
Redis depends on a separate trust anchor and update schedule per host.
-
Migration cost grows with time. Every host provisioned now without a
Valkey path is a future migration. The valkey-redis-compat tooling on Ubuntu
and Valkey's wire compatibility make an early switch cheap; deferring it does
not.
Facts: RHEL / Rocky (default repos + EPEL, verified 2026-05-24)
| EL |
redis (distro / EPEL) |
valkey (distro / EPEL) |
| 8 |
- |
EPEL 8.0.9 |
| 9 |
AppStream |
AppStream 8.0.7 |
| 10 |
not shipped |
AppStream 8.0.7 |
Since RHEL 10 makes Valkey the default key-value store, LFOps needs a supported
path that does not depend on Redis there.
Facts: Debian / Ubuntu (default repos, verified 2026-05-24)
| Distro |
redis-server |
valkey-server |
| Debian 12 (bookworm) |
7.0.15 |
not available |
| Debian 13 (trixie) |
8.0.2 |
8.1.1 |
| Ubuntu 22.04 (jammy) |
6.0.16 |
not available |
| Ubuntu 24.04 (noble) |
7.0.15 |
7.2.12 (+ valkey-redis-compat) |
Key differences from RHEL:
- Redis is not dropped. Unlike RHEL 10, Debian and Ubuntu keep
redis-server
in every current release. There is no "no key-value store" gap to fill.
- Both coexist in the newest releases. Debian 13 and Ubuntu 24.04 ship redis
and valkey side by side from the default repos, no third-party repo needed.
- Older suites (Debian 12, Ubuntu 22.04) have redis only; valkey arrived later.
- Ubuntu 24.04 also ships
valkey-redis-compat (conversion script and
Redis-compat symlinks), which eases a redis-to-valkey migration.
License note (applies to all platforms)
Redis left the OSI-approved open-source path in 2024 (SSPLv1 / RSALv2, starting
with Redis 7.4). Redis 8.0 (2025) re-added AGPLv3 as an option, so Debian 13's
redis 8.0.2 is OSI-open again, while Debian 12 / Ubuntu redis predate the
relicense and are BSD. Valkey (Linux Foundation, BSD) sidesteps this churn
entirely and is the safer long-term default where open-source-only constraints
apply.
The Remi repo problem in this context
Today the redis role can pull an up-to-date Redis from the Remi repo. On
RHEL 10 this is problematic:
- Remi ships real Redis only as module streams (
redis remi-7.2 ..
remi-8.8, 8.8 is rc1, latest stable 8.6). There is no plain/versioned
redis package in remi-safe.
- Remi ships Valkey also only as module streams (
valkey remi-8.1,
remi-9.0, remi-9.1). No plain valkey package in remi / remi-safe.
- Module streams are deprecated on RHEL 10 (see the linked repo_remi issue).
So on RHEL 10 the only non-module key-value store is valkey from the AppStream
(8.0.7). Remi would only add value for newer Valkey lines (up to 9.1), and only
via the deprecated module mechanism.
Is Remi even needed from RHEL 10 on?
For Valkey: no. The AppStream ships it without modules. Remi would only be needed
for a newer Valkey major than 8.0, at the cost of relying on deprecated module
streams. Proposal: on RHEL 10, source Valkey from the AppStream and keep Remi out
of the key-value-store path. To be decided as part of this issue.
Alternatives considered
- Stay on Redis via Remi module streams on RHEL 10. Rejected: depends on a
deprecated mechanism and a non-default product.
- Redis from the official redis.io repo (
repo_redis) on RHEL 10. Possible but
swims against the distro default and the license situation.
Additional context
Related: #262 (repo_remi / module streams on RHEL 10).
Describe the solution you would like
Add a
valkeyrole (and an accompanyingrepo_valkeyrole if a dedicated repois needed) to install and configure Valkey as a drop-in alternative to Redis.
Decide and document a per-platform default for the key-value store used by LFOps
playbooks.
Why this needs to be addressed
The driver differs per platform, which is exactly why a single Valkey path is
worth having:
RHEL 10: forced. No
redispackage exists at all; theredisrole losesits first-party base and falls back to third-party sources (Remi module
streams or redis.io). Valkey from the AppStream is the only supported,
module-free path.
Debian / Ubuntu: license- and consistency-driven. Redis stays available,
but the 2024 relicense and the per-release license churn (BSD -> SSPL ->
AGPLv3) make a stable, BSD-licensed default attractive. Debian 13 and Ubuntu
24.04 already ship Valkey, so LFOps can offer it without third-party repos.
One product across the fleet. Without a Valkey role, RHEL 10 hosts drift
onto a different key-value store (or a third-party Redis) than the Debian /
RHEL 9 hosts. A Valkey role lets us standardise on one Redis-compatible store
across all supported platforms, reducing the support matrix.
Security updates and support. Distro-shipped Valkey (AppStream / Debian /
Ubuntu) gets vendor security backports on the distro cadence; a third-party
Redis depends on a separate trust anchor and update schedule per host.
Migration cost grows with time. Every host provisioned now without a
Valkey path is a future migration. The
valkey-redis-compattooling on Ubuntuand Valkey's wire compatibility make an early switch cheap; deferring it does
not.
Facts: RHEL / Rocky (default repos + EPEL, verified 2026-05-24)
8.0.98.0.78.0.7Since RHEL 10 makes Valkey the default key-value store, LFOps needs a supported
path that does not depend on Redis there.
Facts: Debian / Ubuntu (default repos, verified 2026-05-24)
7.0.158.0.28.1.16.0.167.0.157.2.12(+valkey-redis-compat)Key differences from RHEL:
redis-serverin every current release. There is no "no key-value store" gap to fill.
and valkey side by side from the default repos, no third-party repo needed.
valkey-redis-compat(conversion script andRedis-compat symlinks), which eases a redis-to-valkey migration.
License note (applies to all platforms)
Redis left the OSI-approved open-source path in 2024 (SSPLv1 / RSALv2, starting
with Redis 7.4). Redis 8.0 (2025) re-added AGPLv3 as an option, so Debian 13's
redis 8.0.2is OSI-open again, while Debian 12 / Ubuntu redis predate therelicense and are BSD. Valkey (Linux Foundation, BSD) sidesteps this churn
entirely and is the safer long-term default where open-source-only constraints
apply.
The Remi repo problem in this context
Today the
redisrole can pull an up-to-date Redis from the Remi repo. OnRHEL 10 this is problematic:
redis remi-7.2..remi-8.8, 8.8 is rc1, latest stable 8.6). There is no plain/versionedredispackage inremi-safe.valkey remi-8.1,remi-9.0,remi-9.1). No plainvalkeypackage inremi/remi-safe.So on RHEL 10 the only non-module key-value store is
valkeyfrom the AppStream(8.0.7). Remi would only add value for newer Valkey lines (up to 9.1), and only
via the deprecated module mechanism.
Is Remi even needed from RHEL 10 on?
For Valkey: no. The AppStream ships it without modules. Remi would only be needed
for a newer Valkey major than 8.0, at the cost of relying on deprecated module
streams. Proposal: on RHEL 10, source Valkey from the AppStream and keep Remi out
of the key-value-store path. To be decided as part of this issue.
Alternatives considered
deprecated mechanism and a non-default product.
repo_redis) on RHEL 10. Possible butswims against the distro default and the license situation.
Additional context
Related: #262 (repo_remi / module streams on RHEL 10).