The Valkey and Redis Split: Life After the License Fight

Description and use

Many production systems run outdated Redis 7.x images under SSPL/RSAL, missing critical security patches. By auditing container images, updating to Redis 8 (AGPLv3) or Valkey (BSD‑3), and aligning OS packages and monitoring, licensing and security risks are mitigated.

Problem

Many production systems unknowingly run outdated Redis 7.x images under SSPL/RSAL licenses, exposing them to unpatched security vulnerabilities and licensing risks.

Outcome

By auditing container images, updating to the latest Redis 8 or Valkey releases, and aligning system packages and monitoring, the author mitigated licensing exposure and applied critical security patches, ensuring compliance and operational integrity.

Workflow

• 1. Run docker ps and inspect running images. 2. Verify image tags and pull dates. 3. Check redis-server --version and INFO server for license and version. 4. Identify unpatched security releases via Redis release notes. 5. Decide on target engine (Redis 8 or Valkey). 6. Update Dockerfiles or compose files to use the chosen image tag. 7. Pull the new image and redeploy containers. 8. Update system package managers (apt, dnf) to install the appropriate package (redis-server or valkey-server). 9. Adjust configuration paths, service units, and backup scripts to match the new package. 10. Update monitoring dashboards to read the correct redis_version or valkey_version fields. 11. Verify that security patches are applied and no license violations remain.

Evidence

The 7.4 series is distributed under RSALv2 or SSPLv1, so the "return to open source" that AGPLv3 delivered covers neither machine.

Source

The release notes for Redis 7.4.11 mark its urgency as SECURITY and close, among other things, an ACL key-permission bypass in SORT and XREAD.

Source

Debian trixie ships both packages: redis-server 5:8.0.2 and valkey-server 8.1.1.

Source