Redis 8 went AGPL — can I still use Redis?
Teams choosing Redis distributions or managed offerings need to reassess legal and operational risk after Redis 8 added AGPL alongside RSAL and SSPL, especially where Valkey or cloud-managed alternatives are already under consideration.
Blockers
- Redis 8+ tri-licensed under RSALv2, SSPLv1, and AGPLv3; AGPL is OSI-approved but copyleft — network use of modified versions triggers source-availability obligations; not equivalent to Redis 7.2 BSD-3
- Redis 8.6 includes RedisJSON, RedisBloom, RedisTimeSeries as unified package without separate modules
- replaces: vendor/valkey → vendor/redis
- Snapshot copy, replication, or key-by-key migration from Redis OSS 7.2-compatible versions — Redis CE 7.4 and later data files are not compatible with Valkey; cannot do direct in-place jump from CE 7.4+ — Pain: medium
- ElastiCache for Valkey: zero-downtime upgrade from ElastiCache for Redis OSS; supports Valkey 8.2, 8.1, 8.0, 7.2.6 — Version cadence follows AWS not upstream; 100 MB minimum metered data storage floor on Serverless; serverless pricing 33% lower than other engines — Pain: low
- AGPL copyleft: network use of modified Redis triggers source-availability obligations; RSALv2 forbids managed-service commercialization; SSPLv1 requires public release of management layers
- package/redis-8.6 incompatible with package/valkey-9.0.3: Redis CE 7.4 and later data files are NOT compatible with Valkey; cannot do direct in-place migration from Redis 7.4+/8.x to Valkey
Who this is for
- enterprise
- compliance
- low-ops
- cost-sensitive
- small-team
- high-scale
- real-time
Candidates
Redis Open Source 8 under AGPLv3
As of 2026-03-15, Redis says Redis Open Source 8 and later are available under a tri-license of RSALv2, SSPLv1, and AGPLv3, and AGPLv3 is the OSI-approved open-source option. Redis's official release notes list Redis Open Source 8.6.0 from February 2026 as the latest 8.x release, and Redis 8.6 docs describe a unified package that includes functionality such as RedisJSON, RedisBloom, and RedisTimeSeries without separate modules.
When to choose
Best for compliance + enterprise or small-team + real-time cases where policy requires an OSI-approved license but you still want current upstream Redis 8 features, integrated data structures, and the official Redis release line. Use this when your blocker is source-license acceptability rather than managed-service resale rights, and you are prepared for AGPL obligations if you modify and run the software over a network, as of 2026-03-15.
Tradeoffs
You get the current Redis 8 feature line under an OSI-approved license and stay aligned with Redis's latest upstream releases. The tradeoff is AGPL copyleft: Redis explicitly contrasts AGPL with the older BSD-3 license and notes that network use of modified versions triggers source-availability obligations.
Cautions
Do not treat AGPL as equivalent to the BSD-3 terms from Redis 7.2 and earlier. Redis's licensing page says 7.2 and earlier remained BSD-3, while Redis Community Edition 7.4 through 7.8 used only RSALv2 or SSPLv1. Legal review is still required if you modify Redis and expose it over a network.
Redis Open Source 8 under RSALv2 or SSPLv1
As of 2026-03-15, Redis still offers RSALv2 and SSPLv1 alongside AGPLv3 for Redis Open Source 8 and later. Redis says RSALv2 allows use, copying, distribution, and derivative works but forbids commercializing the software or providing it as a managed service to third parties, while SSPLv1 requires public release of modifications and management layers if you provide the product as a service.
When to choose
Best for enterprise + high-scale or real-time + small-team environments that need official upstream Redis 8 behavior and already have internal approval for Redis's source-available licenses, especially when you are not offering a Redis-like managed service to customers. As of 2026-03-15, this is mainly a continuity path for organizations that already cleared RSAL or SSPL during the 7.4 to 7.8 era and want to stay on Redis's main feature line.
Tradeoffs
This keeps you on official Redis 8 without taking AGPL specifically. The tradeoff is license friction: Redis states that neither RSALv2 nor SSPLv1 is an open-source license, and each has materially different restrictions for hosted-service and derivative-work scenarios.
Cautions
Do not collapse RSAL and SSPL into the same risk profile. RSAL blocks managed-service commercialization, while SSPL allows service use only with strong source-release obligations. Re-run legal review instead of assuming a pre-2025 Redis or fork decision still applies after Redis 8 added AGPL.
Valkey
As of 2026-03-15, the Valkey project describes itself as an open-source BSD high-performance key/value datastore backed by the Linux Foundation. Valkey's download page lists version 9.0.3 as the current release and 8.1.6 as the latest supported 8.x release, while Valkey's migration guide says Redis Community Edition 7.4 and later are not open source and their data files are not compatible with Valkey.
When to choose
Best for compliance + enterprise or cost-sensitive + small-team cases where you want permissive licensing, community governance, and a clean alternative to Redis's AGPL, RSAL, and SSPL choices. Use it when the main requirement is minimizing future license surprise and you can accept a separate product roadmap from upstream Redis 8, especially if your estate is still close to Redis OSS 7.2-era compatibility.
Tradeoffs
You get a BSD-licensed project with Linux Foundation stewardship and documented migration paths such as snapshot copy, replication, and key-by-key migration from compatible Redis versions. The tradeoff is roadmap divergence from Redis 8: Valkey is not just a license wrapper for current Redis Open Source releases.
Cautions
Do not assume a direct in-place jump from Redis Community Edition 7.4 or later. Valkey's migration docs explicitly say those releases are not open source and their data files are not compatible with Valkey. Validate feature parity, module needs, and migration method before committing.
Amazon ElastiCache for Valkey
As of 2026-03-15, AWS offers Amazon ElastiCache for Valkey as a managed option with serverless pricing 33% lower and node-based pricing 20% lower than other supported engines, and AWS says you can get started as low as $6 per month. AWS documentation says ElastiCache supports Valkey 8.2, 8.1, 8.0, and 7.2.6, and the pricing docs say Serverless for Valkey has a 100 MB minimum metered data storage floor.
When to choose
Best for low-ops + high-scale or enterprise + compliance teams already on AWS that want permissive-license direction via Valkey while avoiding self-hosting and migration toil. As of 2026-03-15, this is the strongest fit when you want a managed path off ElastiCache for Redis OSS with AWS-operated availability, autoscaling, and documented engine switching support.
Tradeoffs
You reduce licensing ambiguity and operational burden, and AWS documents zero-downtime upgrades from ElastiCache for Redis OSS to ElastiCache for Valkey. The tradeoff is platform coupling: version cadence, pricing mechanics, and feature availability follow AWS rather than upstream Valkey or Redis release timing.
Cautions
Do not assume every upstream Redis 8 capability appears on the same timeline in AWS. AWS says ElastiCache for Valkey supports most features available in ElastiCache version 7.2 for Redis OSS by default, and its supported-version list is specific to AWS-managed engine releases. Validate required commands, modules, and migration behavior before standardizing.
Try with your AI agent
$ npm install -g pocketlantern $ pocketlantern init # Restart Claude Code, Cursor, or your MCP client, then ask: # "Redis 8 went AGPL — can I still use Redis?"