Redis and Valkey Release History: 2009 to Redis 8 and Valkey 8

Redis started in 2009 as Salvatore Sanfilippo's in-memory data store and stayed under the BSD 3-Clause licence through Redis 7.2. On 20 March 2024 Redis announced that 7.4 and later would ship under RSALv2 or SSPLv1, and on 28 March 2024 the Linux Foundation announced Valkey, a BSD licensed continuation of Redis 7.2.4. Redis 8 (2 May 2025) added AGPLv3 as a third licence option, and Valkey 8.0 (15 September 2024) was the fork's first major release.

As of 25 October 2026 the newest Redis Open Source line is 8.10 (8.10.2, released 17 September 2026), and the newest stable Valkey line is 9.1 (9.1.2, released 31 August 2026), with Valkey 9.2.0 at its first release candidate. Both still ship the security defaults Redis built up over a decade: protected mode since 3.2, ACLs and TLS since 6.0, and a configuration file that binds to loopback.

Key takeaways

• Sponsorship moved from VMware (March 2010) to Pivotal, then to Redis Labs (July 2015), now Redis Ltd. Sanfilippo stepped back on 30 June 2020 and rejoined the company in November 2024.
• Licence by version: Redis 7.2.x and earlier are BSD 3-Clause; 7.4.x to 7.8.x are RSALv2 or SSPLv1; Redis 8 and later are RSALv2, SSPLv1 or AGPLv3, at the user's choice. Redis's own licence page says RSALv2 and SSPLv1 are not open source licences and AGPLv3 is OSI approved.
• The modules moved first: AGPL to Apache 2.0 with Commons Clause (August 2018), RSAL (February 2019), then RSALv2 or SSPLv1 (November 2022).
• Valkey continues from Redis 7.2.4 under BSD 3-Clause. Its first GA was 7.2.5 on 16 April 2024, and no single organisation may hold more than one third of its Technical Steering Committee.
• Protected mode arrived in Redis 3.2, ACLs and TLS in 6.0, and Redis 7.0 blocked pub/sub channels for new users and disabled DEBUG and MODULE by default. rename-command is now marked DEPRECATED in favour of ACLs.
• A Valkey server still reports redis_version:7.2.4 in INFO for compatibility, so an inventory that reads only that field records Valkey as Redis.

How did Redis begin, and who sponsored it?

Redis was written by Salvatore Sanfilippo, known as antirez. The Linux Foundation's March 2024 announcement dates the project's founding to 2009. In a post dated 15 March 2010, Sanfilippo wrote that Redis "started as an internal project more or less one year ago", built to scale parts of web applications he worked on and released publicly a few weeks later. That post announced the first sponsorship: VMware hired him to work on Redis full time. It also lists the features already landing then: sorted sets, virtual memory (later removed) and the append only file.

When VMware moved its data products into Pivotal, Redis sponsorship went too. In July 2015, in "Thanks Pivotal, Hello Redis Labs", Sanfilippo thanked "Pivotal, and VMware before" for keeping Redis a "pure" OSS project, explained that he had chosen not to start a Redis company, and announced his move to Redis Labs. Redis Labs is now Redis Ltd, the licensor named in the current licence files.

On 30 June 2020 he published "The end of the Redis adventure" and stepped back. The Redis 6.2 RC1 notes (December 2020) call 6.2 "the first significant Redis release managed by the core team under the new project governance model". A Redis blog post from May 2025 says he rejoined the company in November 2024 as a developer evangelist and created vector sets, the first new data type in Redis 8.

Redis release timeline: the versions that mattered

Dates come from the 00-RELEASENOTES file on each branch of the Redis GitHub repository. The 2.6 notes carry no date for 2.6.0.

The early years: 1.x to 2.8

The first versions set the shape Redis still has: a single threaded event loop, a small text protocol, data in memory and optional persistence through RDB snapshots and later the AOF. The 2.6 notes record the Lua scripting engine and the Sentinel backport; the 2.8 notes add a rewritten Sentinel, the SCAN, SSCAN, HSCAN and ZSCAN commands, and PSYNC so a replica could resume after a short disconnect instead of copying everything again.

Security was blunt. Redis was designed for trusted clients on trusted networks, the shared requirepass password was off by default, and the default configuration listened on all interfaces. That combination is why protected mode exists.

Redis 3.x: Cluster and protected mode

Redis 3.0.0 (1 April 2015) shipped Redis Cluster, "a distributed implementation of a subset of Redis" in its own release notes, splitting the keyspace into hash slots across nodes. Redis 3.2.0 followed on 6 May 2016. Its RC2 notes (25 January 2016) describe protected mode as a feature that "improves Redis security and makes harder to run Redis in a configuration that is unsecure because no firewalling was used". The Redis security documentation explains that since 3.2.0, a server running with the default configuration and no password only answers loopback clients and sends everyone else an error explaining how to configure it.

Redis 4.0 and 5.0: modules and streams

Redis 4.0.0 (14 July 2017) introduced modules. Its notes say it was not called 3.4 because it reworked many core functions. A quieter change mapped the HTTP words POST and Host: to QUIT, so a browser tricked into sending a request to a Redis port is disconnected; the notes call this a defence against "cross protocol scripting attacks". Modules matter here twice: technically they let search, JSON and time series ship outside the core, and commercially their licences were where Redis Labs first moved away from open source terms. Redis 5.0.0 (17 October 2018) added the Stream data type.

Redis 6.0 and 6.2: ACLs, TLS and new governance

The 6.0 RC1 notes (19 December 2019) list among the biggest features "Redis now supports SSL on all channels" and ACLs where "you can define users that can run only certain commands and/or can only access only certain keys patterns". GA followed on 30 April 2020.

ACLs were built to be backward compatible. The Redis ACL documentation says that in the default configuration Redis 6 "works exactly like older versions of Redis": every connection can run every command on every key. requirepass now sets the password of the user called default, and an untouched server reports user default on nopass ~* &* +@all from ACL LIST. TLS is opt in: the current redis.conf still says "By default, TLS/SSL is disabled".

Redis 7.0 to 7.4: safer defaults and the last BSD release

Redis 7.0.0 (27 April 2022) introduced Functions and ACL selectors, and changed three security defaults, all in its release notes:

• "ACL: pub/sub channels are blocked by default (acl-pubsub-default=resetchannels)".
• "MODULE and DEBUG commands disabled (protected) by default, for better security", controlled by enable-debug-command, enable-module-command and enable-protected-configs, each defaulting to no.
• "Improve bind and protected-mode config handling".

Redis 7.2.0 (15 August 2023) is the last BSD line. Redis 7.4.0 (29 July 2024) is the first under the new licences; its RC1 entry opens with "Note: License changed - see LICENSE.txt", and its headline feature is expiration of individual hash fields through nine new commands such as HEXPIRE and HTTL.

Redis 8.x: Redis Open Source and the tri licence

The Redis 8.0.0 GA notes (2 May 2025) list a name change from Redis Community Edition to Redis Open Source, a licence change to "your choice of" RSALv2, SSPLv1 or AGPLv3, the Query Engine, JSON, time series and five probabilistic structures built into every binary distribution, vector sets marked beta, new ACL categories such as @search and @json, and a new I/O threading implementation. They add that standalone RediSearch, RedisJSON, RedisTimeSeries and RedisBloom "are no longer needed as they are now part of Redis". The 8.10 notes (29 July 2026) list compact hashes, a BACKUP command and "TLS peer certificate-based server-to-server authentication".

What changed in Redis licensing, and when?

Redis licensing changed in five steps over seven years. The core stayed BSD until 2024; the modules moved first.

2018 and 2019: the modules

In August 2018 a Redis Labs page about Commons Clause was widely read as Redis itself changing licence. On 22 August 2018 Sanfilippo wrote that "Redis is, and will remain, BSD licensed", and the company's post "Redis' License is BSD and will remain BSD" explained that only certain modules had moved from AGPL to Apache 2.0 modified with Commons Clause, which allows selling products built on the modules but not the modules themselves.

On 21 February 2019 the modules moved to RSAL. The post cites confusion over the "Apache2 modified by Commons Clause" wording, the unclear word "substantial" and a restriction on "support". It says RSAL lets developers use, modify and sell their applications, provided the application "cannot be a database, a caching engine, a stream processing engine, a search engine, an indexing engine or an ML/DL/AI serving engine", and that the change "has zero effect on the Redis core license".

March 2024: RSALv2 and SSPLv1 for the core

On 20 March 2024 Redis announced that "Starting with Redis 7.4, Redis will be dual-licensed under the Redis Source Available License (RSALv2) and Server Side Public License (SSPLv1)" and "will no longer be distributed under" BSD. The FAQ states that "neither RSALv2 nor SSPL is an OSI-approved license", says there is no change for internal or personal use, keeps Redis client libraries open source, and announced the end of life of Redis Stack once Redis 8 shipped. The company's stated reason was that most of its commercial sales went through the largest cloud providers, which would now need a licensing agreement to offer Redis 7.4 and later as a service.

May 2025: AGPLv3 joins with Redis 8

On 1 May 2025 Redis announced "the OSI-approved AGPL as an additional licensing option for Redis, starting with Redis 8", with the former Redis Stack technologies integrated into core Redis 8. The post acknowledges that the March 2024 change "hurt our relationship with the Redis community". The licence page calls the result a tri licence, "not a license change, but rather the inclusion of an option", and gives the map:

LICENSE.txt in the repository says new contributions from Redis 8 fall under an updated software grant and contributor licence agreement, and that 7.2 and earlier "remain subject to the BSDv3 clause license". It contains the full texts of RSALv2 (last updated 30 December 2023), SSPLv1 and AGPLv3.

What each licence asks of you, in the projects' own words

This is not legal advice and does not rank licences. It restates only what Redis's licence page and the licence files say.

Two details are often missed. The choice is the user's: Redis 8 is offered under any one of the three. And Redis SECURITY.md lets users of 7.2 and earlier take security patches released under 7.4 and later under BSD 3-Clause, while warning that fixes are tested only on the versions they ship for and portability to forks "has not been evaluated".

For the general question, see whether a source available licence is open source and what to do when a dependency is relicensed.

What is Valkey, and how is it governed?

Valkey is a BSD 3-Clause in-memory data store that continues from Redis 7.2.4 under the Linux Foundation. The foundation announced its intent to form Valkey on 28 March 2024, saying it "will continue development on Redis 7.2.4 and will keep the project available for use and distribution under the open source Berkeley Software Distribution (BSD) 3-clause license". The release describes former Redis contributors and maintainers regrouping "in response to the recent license change announced by Redis Inc.", backed by several large cloud and technology companies. Valkey's COPYING file carries both "Copyright (c) 2024-present, Valkey contributors" and "Copyright (c) 2006-2020, Redis Ltd."

Valkey's first releases

Valkey's 7.2 notes record 7.2.4 RC1 on 9 April 2024 and the first GA, 7.2.5, on 16 April 2024. The 8.0 announcement says that release "focused on compatibility and license continuity; bringing no new features". The rename changed what inventory tools see:

• The six binaries became valkey-server, valkey-cli, valkey-benchmark, valkey-check-aof, valkey-check-rdb and valkey-sentinel, and install creates symlinks from the old Redis names.
• INFO gained valkey_version and server_name, while "redis_version will continue to be present and will indicate the Redis OSS version that the server is compatible with". The 9.1 source still sets it to 7.2.4, with a comment that it "should never exceed 7.2.x".
• RDB files gained a valkey-ver field, and a new valkeymodule.h header arrived while Valkey stays ABI compatible with Redis modules.

How Valkey is governed

GOVERNANCE.md puts Valkey under a Technical Steering Committee (TSC) of the main repository's maintainers. No more than one third of members may come from the same organisation or its affiliates; if that limit is broken, the TSC aims to restore compliance within 30 days. Technical major decisions (new data structures or APIs, compatibility changes, new user visible fields) need a simple majority, or two explicit approvals when no member objects. Governance changes need a two thirds super majority. Discussions are public except embargoed security issues and maintainer changes.

What did Valkey 8 add?

Valkey 8.0.0 reached GA on 15 September 2024 after RC1 on 1 August and RC2 on 2 September. The GA post calls it "the first major release" and says it makes "no backwards incompatible changes to the existing command syntax or their responses". The RC1 notes list asynchronous I/O threading, more reliable cluster scaling, a dual channel for primary to replica full sync, per slot metrics through CLUSTER SLOT-STATS, experimental RDMA support, and full compatibility with Redis OSS 7.2.4.

How did Redis and Valkey security defaults evolve?

Both projects share the pre-2024 defaults, and today's redis.conf and valkey.conf match on the key lines: bind 127.0.0.1 -::1, protected-mode yes, and enable-protected-configs, enable-debug-command and enable-module-command all documented as no.

Protected mode, bind and the default user

Protected mode is a safety net, not access control. The redis.conf comment says it applies "when protected mode is on and the default user has no password", limiting connections to 127.0.0.1, ::1 or Unix sockets. Set an explicit routable bind, or give the default user a password, and it no longer restricts anything; the security docs note an administrator "can still ignore the error given by Redis and disable protected mode or manually bind all the interfaces". The real control is the user list. For the hands-on fixes, see replacing the default user with nopass and protected mode, bind and firewalls.

Why rename-command is deprecated

Renaming CONFIG or FLUSHALL to a random string, or to an empty string, was the standard pre-ACL hardening. Both config files now put a warning above it: "avoid using this option if possible. Instead use ACLs to remove commands from the default user, and put them only in some admin user you create for administrative purposes." They also warn that renaming commands logged to the AOF or sent to replicas "may cause problems". ACLs do the same job per user and show up in ACL LIST.

How do Redis and Valkey publish security fixes and support windows?

Redis

Redis SECURITY.md recommends the latest version and says "We generally backport security issues to a single previous major version, unless this is not possible or feasible with a reasonable effort." Its table, fetched on 25 October 2026:

Reports go through the Redis Vulnerability Disclosure Program or GitHub's private reporting. For critical issues that are not yet public, Redis may notify a short list of vendors under a time limited embargo. Every release notes entry starts with an upgrade urgency (LOW, MODERATE, HIGH, CRITICAL or SECURITY), and on 17 September 2026 the same fixes shipped as 8.4.7, 8.6.7, 8.8.3 and 8.10.2.

Valkey

Valkey's SECURITY.md asks reporters to email security@lists.valkey.io rather than open an issue, and says vendors may be notified before public release depending on severity. Its release policy follows semantic versioning, "typically releases a stable major version once each year", gives each minor three years of bug and security fixes, and gives the last minor of each major five years of security fixes. The TSC patches issues "we believe to be possible to exploit".

The same page advises against running a cluster on mixed minor versions and says to upgrade replicas before primaries.

Redis and Valkey side by side

Commands added after the fork exist on one side only, such as Redis 8.0's HGETDEL or Valkey 9.0's DELIFEQ. If your application uses only commands that existed in 7.2.4, both servers accept it; otherwise test against the exact server and version you plan to run.

Step by step: find out what you run, what licence it carries and how it is configured

Steps 1 to 4 are read only. Run everything against staging first, and pass passwords through ACL users or prompts rather than on the command line.

Step 1: ask the server what it is

# Works against Redis and Valkey. Valkey installs redis-cli as a symlink to valkey-cli.
redis-cli -h 127.0.0.1 -p 6379 INFO server | grep -E '^(server_name|redis_version|valkey_version|redis_mode|executable|config_file):'

Redis reports redis_version only. Valkey reports server_name:valkey and valkey_version, and its redis_version is the compatibility version, 7.2.4. Record valkey_version for Valkey.

Step 2: check what is inside your images and packages

docker exec -it my-cache sh -c 'ls -l /usr/local/bin/ | grep -E "redis|valkey"; redis-server --version 2>/dev/null; valkey-server --version 2>/dev/null'
command -v redis-server valkey-server

If redis-server is a symlink to valkey-server, the image ships Valkey, whatever it is called.

Step 3: check the licence your SBOM records

For a CycloneDX JSON SBOM, list the component with its version and declared licence:

jq -r '.components[]
  | select(.name | test("redis|valkey"; "i"))
  | [.name, .version, ((.licenses // []) | map(.license.id // .license.name // .expression) | join(" | "))]
  | @tsv' sbom.cdx.json

Compare the result with Redis's version map: 7.2.x should say BSD-3-Clause, 7.4.x RSALv2 or SSPLv1, and 8.x the three options. An empty licence field, or a Redis 8 component marked BSD-3-Clause, means the tool guessed. With the Safeguard CLI you can produce the component list for an image or repository:

safeguard scan --image my-registry.example.com/cache:2026-10
safeguard scan --dir .
# Results are written as JSON under ./output

Step 4: audit users and defaults

redis-cli ACL LIST
redis-cli CONFIG GET protected-mode
redis-cli CONFIG GET bind
redis-cli CONFIG GET acl-pubsub-default
redis-cli CONFIG GET enable-debug-command
redis-cli CONFIG GET enable-module-command

user default on nopass means any client that reaches the port has full access. +@all on an application user usually means nobody scoped it. If protected-mode is no and bind includes a routable address, the network is your only control.

Step 5: replace the default user (changes configuration)

This step changes access control. Create and test an admin user before you disable default, or you will lock yourself out.

redis-cli ACL SETUSER admin on '>use-a-long-random-secret' '~*' '&*' '+@all'
redis-cli --user admin --askpass ACL WHOAMI
redis-cli --user admin --askpass ACL SETUSER app on '>another-long-random-secret' '~app:*' '+@read' '+@write' '-@dangerous'
redis-cli --user admin --askpass ACL SETUSER default off
redis-cli --user admin --askpass ACL SAVE   # only if you use an ACL file

Then remove any rename-command lines and express the same intent as ACL rules.

Step 6: test a migration in staging

1. Read the release notes for every version between source and target, especially breaking changes and RDB format notes (Redis 7.0 moved to RDB version 10, 7.2 to version 11).
2. Confirm the target can read the source's RDB format before planning a snapshot based cutover.
3. Where versions allow, run the target as a replica of the source in staging and let it sync.
4. Run your test suite against the target, including scripts, functions and modules.
5. Check that each client library supports the target and the commands you use; CLIENT SETINFO names show which libraries connect.
6. Upgrade replicas before primaries.
7. Update the SBOM, licence register and inventory with the new server name and version.

Common mistakes

• An SBOM that says redis when the image ships Valkey, or the reverse. Valkey installs Redis named symlinks and reports redis_version. Read server_name and valkey_version.
• Matching advisories against the compatibility version. A Valkey 9.1 server reports redis_version:7.2.4; advisory matching on that number is wrong in both directions.
• Assuming a licence from the product name. "Redis" covers three licence regimes by version. Record the exact version and use Redis's own map.
• Misreading licence obligations. RSALv2 restricts offering the software as a managed service; SSPLv1 and AGPLv3 attach conditions to providing it as a service or over a network; the 2024 FAQ says internal use is unaffected. Have your legal team map these to your actual use.
• Leaving the default user with nopass. Protected mode stops helping once you bind to a routable address.
• Keeping rename-command as the main control. It is deprecated, can break replication and AOF, and hides intent.
• Client libraries pinned to deprecated commands. Valkey majors may remove previously deprecated commands; test clients against the target first.
• Assuming newer means supported. Redis 8.0.x is unsupported in SECURITY.md while 7.4.x and 7.2.x are supported.

FAQ

Is Redis still open source?

Redis 8 and later can be used under AGPLv3, which Redis's licence page calls an OSI approved open source licence, or under RSALv2 or SSPLv1, which the same page says are not. Redis 7.4.x to 7.8.x are RSALv2 or SSPLv1 only. Redis 7.2 and earlier remain BSD 3-Clause.

When did Redis change its licence?

On 20 March 2024 Redis announced RSALv2 or SSPLv1 for Redis 7.4 and later, replacing BSD 3-Clause. On 1 May 2025 it added AGPLv3 as a third option from Redis 8.

What is Valkey, and who maintains it?

A Linux Foundation project, announced on 28 March 2024, that continues from Redis 7.2.4 under BSD 3-Clause. A Technical Steering Committee of maintainers governs it, with no organisation allowed more than one third of the seats.

Is Valkey a drop-in replacement for Redis?

Valkey's 8.0 notes state full compatibility with Redis OSS 7.2.4, and it installs Redis named symlinks. Features added by either project after the fork, including Redis 8's built in Query Engine and JSON, are not shared, so test before switching.

What version of Redis or Valkey am I running?

Run INFO server. On Redis read redis_version. On Valkey read server_name and valkey_version, because its redis_version is the compatibility version.

When was protected mode added to Redis?

It first appeared in the Redis 3.2.0 RC2 notes on 25 January 2016 and shipped in 3.2.0 on 6 May 2016.

Does Redis have users and passwords?

Yes, since Redis 6.0 (April 2020), through ACLs with named users and command, key and channel rules. Every server has a default user, which is enabled with no password until you change it.

Should I still use rename-command?

No. Both redis.conf and valkey.conf mark it deprecated and point to ACLs.

How long is each Valkey version supported?

Three years of bug and security fixes per minor version, and five years of security fixes for the last minor of each major. Valkey 7.2 has security support until 16 April 2029.

Why supply chain hygiene still matters here

Redis and Valkey usually reach production inside container images, Helm charts and base images that teams rebuild without looking at which server, version or licence they picked up. Knowing exactly which component and version each image carries is what lets you apply a security patch, honour a licence decision or plan a migration, and that inventory work is where Safeguard helps.

Fix it without waiting for upstream

Whatever the vulnerability, most of the risk sits in two gaps. The first is the time between a fix being published and that fix actually running in your production builds. The second, and worse, is the time before any fix exists at all, while a maintainer works out a patch and a release schedule. Waiting through both gaps is a habit, not a requirement. Safeguard gives teams three ways to close them.

1. Autonomous remediation: pull requests, not tickets

When a fixed version exists, Safeguard's Griffin models open a tested, policy gated pull request that moves the affected dependency to the safe version. You can run it on one repository or in bulk across every project that carries the vulnerable version. Remediation categories include dependencies, licenses, security posture and findings, and each one is set separately. Reachability analysis ranks the vulnerable code paths your application actually calls first, so the first pull requests you merge are the ones that matter most. Autonomous remediation ships switched off, with every category set to Manual, so your team decides how much runs on its own and what still needs a human approval.

2. Gold Open Source: the safe version in seconds, free

gold.safeguard.sh is free and needs no login. Search any CVE or package to see affected and fixed versions, CVSS, EPSS, CISA KEV status and a recommended safe version, or use the "Am I affected?" checker. The same data is available through a free read API, README status badges and RSS threat feeds.

3. Gold Registry: start from components that are already fixed

Gold Registry provides hardened, drop in replacements for upstream packages and container images. Every Gold artifact is held continuously to zero exploitable critical or high CVEs and a completed license check, with signed build provenance (signed with Safeguard's key and verifiable with cosign, SLSA Build Level 3 as the design target) and a public evidence page you can hand to an auditor. An artifact loses its Gold badge if it regresses. Teams can point their own package directory at the registry so hardened equivalents resolve without changing how developers install anything.

When upstream has no fix yet, or will not ship one, Safeguard first works to get the fix accepted upstream. If the issue is severe or upstream will not move, Safeguard builds a fork, fixes the vulnerability there and publishes a hardened Gold build, so you are not stuck on a maintainer's release schedule. You can also request a hardened, compatibility tested build of a specific package. Ask which packages it covers before you plan around it.

One honest limit: when the vulnerable code lives in a vendor appliance, a hosted service or an operating system runtime you do not build yourself, the fix still has to come from that vendor or distribution. The steps above apply to the open source dependencies and container images you build and ship, which is where most teams carry the largest and least tracked share of their exposure.

See how Safeguard would help

Safeguard does not configure or monitor running Redis or Valkey servers, and it does not audit ACLs, protected mode or TLS settings on a live instance. It also does not give legal advice on licences. Where it helps is the inventory side of this post: finding which repositories, images and SBOMs carry Redis or Valkey at which version, classifying the declared licence through its licence compliance policies (SPDX expression parsing, permissive and copyleft categories, policy as code), and acting on that list.

The first demo sets up the Safeguard runner on your own machine, approves it with a device code, and runs a scan from the terminal. For this topic, that is the step where you point a scan at an image that ships a cache server and get back every component, with its version and declared licence, as JSON you can check against the Redis licence table.

Click through it at your own pace, or open it full screen.

The second demo is a real Safeguard CLI session. You ask it to fix a vulnerable dependency, it reads the finding and the advisory, asks before any command that changes something, edits the manifest, runs the install and tests with your approval, and prints a summary without pushing. The same flow applies when a Redis client library in your application is pinned to an old release that needs to move before a server upgrade.

Click through it at your own pace, or open it full screen.

The third demo connects Claude to the Safeguard MCP server with OAuth and lets you choose which tools Claude can use. That makes it possible to ask, in plain language, which of your projects contain Redis or Valkey components and which versions they carry, before you plan a licence review or a migration.

Click through it at your own pace, or open it full screen.

To try it on your own estate, download Safeguard and follow the CLI docs.

Quick check

Sources

• Redis: Licenses
• Redis: Redis Adopts Dual Source-Available Licensing (20 March 2024)
• Redis: Redis is now available under the AGPLv3 open source license (1 May 2025)
• Redis: Redis' License is BSD and will remain BSD (22 August 2018)
• Redis: Redis Labs' Modules License Changes (21 February 2019)
• Redis GitHub: LICENSE.txt
• Redis GitHub: SECURITY.md
• Redis GitHub: redis.conf
• Redis GitHub: release notes, branches 2.6 to 8.10
• Redis docs: Redis security
• Redis docs: ACL
• antirez: VMware, the new Redis home (15 March 2010)
• antirez: Thanks Pivotal, Hello Redis Labs (2015)
• antirez: Redis will remain BSD licensed (2018)
• antirez: The end of the Redis adventure (2020)
• Linux Foundation: Linux Foundation Launches Open Source Valkey Community (28 March 2024)
• Valkey
• Valkey: Generally Available: Valkey 8.0.0 (16 September 2024)
• Valkey docs: Releases and versioning schema
• Valkey docs: ACL
• Valkey GitHub: repository
• Valkey GitHub: COPYING
• Valkey GitHub: GOVERNANCE.md
• Valkey GitHub: SECURITY.md
• Valkey GitHub: valkey.conf
• Valkey GitHub: release notes for 7.2, 8.0, 8.1, 9.0, 9.1 and 9.2
• Valkey GitHub: src/version.h on the 9.1 branch

Last reviewed: 25 October 2026.