Does AGPL Redis Force You to Open Source Your App? The 2026 Answer
Redis 8 defaults to AGPLv3 after the 2024 SSPL relicense and Valkey fork. What the network clause actually requires, when it bites, and how to pick a store.
Every few months a thread climbs the front page of Hacker News with some variation of the same worry: the database my product depends on just changed its license, and now I do not know what I am allowed to do. Redis is the one that keeps coming back. It went from BSD to a source-available pair in 2024, the community forked it into Valkey, and then Redis 8 added AGPLv3. The comparison pieces about which fork to pick are everywhere. The question that actually keeps people up at night is narrower and rarely answered cleanly: if I run AGPL Redis behind my SaaS, do I now have to open source my application? We have read the license, the Redis announcements, and the lawyerly hedging, so here is the honest version.
What actually changed, in order
It helps to get the timeline straight, because the panic usually comes from conflating the two events.
In March 2024 Redis Ltd. dropped the permissive BSD 3-Clause license that Redis had carried for over a decade. It moved to a dual model: the Redis Source Available License v2 (RSALv2) and the Server Side Public License v1 (SSPLv1). Neither is OSI-approved open source. The SSPL in particular is written to stop cloud providers from offering Redis as a managed service without contributing back, and the Open Source Initiative has been explicit that it does not meet the open source definition. Within weeks, AWS, Google Cloud, and Oracle backed a fork of the last BSD version (Redis 7.2.4) called Valkey, now under the Linux Foundation and still BSD-3-Clause.
In November 2024 Salvatore Sanfilippo, Redis's original author, rejoined the company. With Redis 8, released in May 2025, Redis added the GNU Affero General Public License v3 (AGPLv3) as a third option alongside RSALv2 and SSPLv1. AGPLv3 is OSI-approved, so Redis can again call itself open source. The earlier two licenses did not go away; Redis 8 is tri-licensed and you pick one.
So the relevant fact for a developer in 2026 is this: a fresh redis:8 you pull today is, by default, AGPLv3 software. That is the one whose terms you need to understand.
The question everyone actually asks
The AGPL has a reputation as the license that "infects" anything it touches over a network. That reputation is half right and it scares people into the wrong conclusion. The defining clause of AGPLv3, the one GPLv3 lacks, is section 13: if you run a modified version of the program and let users interact with it remotely over a network, you must offer those users the corresponding source of your modified version. This was written precisely to close the "SaaS loophole" where a company could modify GPL software, host it, and never distribute the changes.
Two words in that sentence are load-bearing, and missing them is where the fear comes from.
The first is modified. The network-source obligation in section 13 is triggered by running a modified Redis, not by running Redis. If you pull the official Redis image and use it as shipped, you have not modified it, so section 13 has nothing to demand from you.
The second is the program. The AGPL's reach is the licensed work and works derived from it, not every process that happens to talk to it. Your application connecting to Redis over the network protocol, the way every app does, is a normal client-server relationship. Your code calls SET and GET; it does not link Redis's source into your binary. The Free Software Foundation's own position is that communicating over a socket or a documented protocol is generally an arm's-length boundary, not the kind of combination that creates a derivative work. The aggressive "AGPL eats your whole stack" reading does not survive contact with how the FSF actually describes the boundary.
Put plainly: using unmodified AGPL Redis as the database behind your closed-source SaaS does not obligate you to release your application's source. Your business logic, your schema, your routes stay yours. We are not your lawyers, and a cautious legal team is entirely within its rights to want zero AGPL anywhere near the product. But the common belief that merely depending on AGPL Redis forces you to open source your app is not what the license says.
Where the obligation is real, and where the real friction lives
There are situations where AGPL genuinely bites, and they are worth naming so the line is clear.
If you fork Redis and patch the engine, then run that patched build as a service users reach over the network, section 13 applies and you owe those users the source of your modifications. If you embed or statically link Redis modules into a single distributed artifact, you are in derivative-work territory and the copyleft applies to that artifact.
The more common friction is not legal at all, it is procurement and policy. Plenty of companies maintain an allow-list of licenses, and a growing number of them now flag AGPL outright regardless of the modification nuance, because reasoning about section 13 per dependency is more effort than just saying no. Peter Zaitsev of Percona summed up the mood by calling AGPL "probably the most restrictive popular open source license out there." Even though Redis is technically open source again, the AGPL label alone is enough to get it removed from some default stacks. That, more than any actual source-disclosure event, is why teams keep asking the question.
How this maps to choosing a store in 2026
The relicensing is, ironically, clarifying. It forces a decision that was always there but easy to ignore. There are now three honest options and the right one depends on what you actually need.
Stay on Redis 8 under AGPLv3 if you run it unmodified and your legal posture is comfortable with the AGPL label. You get the latest engine, the full command surface, and the active development. For a self-hosted, unmodified deployment behind a SaaS, this is fine far more often than the internet implies.
Move to Valkey if you want a permissive BSD-3-Clause license and a community-governed project with no copyleft to reason about at all. It is a drop-in for Redis 7.2-era workloads, it ships as the default in major Linux distributions now, and the wire protocol is identical, so your clients do not change. If the AGPL label itself is the blocker, this is the path of least resistance and it is covered in more depth in our Key-Value Store vs Redis in 2026 writeup.
Step outside the in-memory category entirely if the license question is really a proxy for a cost or operations question. A lot of the workloads people run on Redis are not latency-critical, fit in a single node, and are mostly cold, which means they are paying RAM prices for data that rarely gets touched. A disk-first store that speaks the Redis protocol is its own answer to a different problem. That is the lane BaseKV sits in: it is a persistent, BoltDB-backed key-value engine that answers RESP, so existing clients connect unchanged, and its own code is not AGPL, so it does not bring the section 13 conversation along with it. It is not a Redis replacement for a pure-RAM, 100K-requests-per-second workload, and we will not pretend it is. For the large middle of "I just need a durable KV store and I do not want a license footnote in my architecture diagram," it is a clean option among several.
The point is not that any one of these is universally correct. It is that the license change turned a vague unease into a concrete fork in the road, and the worst move is to stay frozen on it out of a misreading of what AGPL requires.
The takeaway
Redis 8 defaults to AGPLv3, which is genuine OSI-approved open source, but the AGPL's network clause only triggers when you run a modified version and expose it to users over a network. Using unmodified Redis as the backend for your closed-source application does not put your code under copyleft, and talking to it over the wire protocol is an arm's-length boundary, not a derivative work. The real cost of AGPL for most teams is policy friction, not a source-disclosure event. If that friction is your blocker, Valkey gives you BSD with an identical protocol, and a permissively licensed disk-first store gives you a different answer if the license worry is really a RAM-cost worry in disguise. Read the license, decide deliberately, and do not let a half-remembered "AGPL is viral" headline make the choice for you.
Related: Key-Value Store vs Redis in 2026, The Best Redis Alternative for Small Datasets, Export Data vs Vendor Lock-In: Why It Matters, Disk-Backed Redis Alternative Explained.