Redis 8.0 End of Life Explained: How to Upgrade to 8.2 Before 1 December 2026

Nothing breaks on the day itself, and that is the trap. Redis 8.0 keeps serving requests, but Redis stops promising security fixes for it. In practice, 8.0 already has known security bugs with no 8.0 fix.

This guide covers Redis 8 end of life for people who run Redis Open Source themselves: on a virtual machine, in Docker or in Kubernetes. If a cloud provider runs Redis for you, its own calendar applies, and a later section covers that.

Picture a common setup. A food delivery app in Pune keeps login sessions, one-time passwords (OTPs), a rate limiter and an order stream in one Redis 8.0 primary with one replica. The setup is made up, but every date and test result in this guide is real.

The team picked 8.0 in 2025 because it was the first Redis 8 release, and "x.0" sounded like the long-term version. Under the release model Redis uses now, it is the opposite. 8.0 is a short-life release, and 8.2 is the long-life one.

You need three terms now. The rest are explained where they first matter.

• Version number. Redis uses MAJOR.MINOR.PATCH. In 8.2.10, 8 is the major version, 2 is the minor version and 10 is the patch number.
• Patch release. A release that only fixes bugs and security holes, such as 8.0.5 to 8.0.6. It is meant to fix things, not add features, but a fix can still change behaviour you rely on.
• End of life (EOL). The date after which Redis stops shipping security updates and critical bug fixes for a version. The software still runs; it just stops getting fixed.

Redis 8 end of life is not one date. Only Redis 8.0 has a printed end date, 1 December 2026. Every other Redis 8 line is either supported for years or has no end date yet.

The table below is copied exactly from the official Redis Open Source version management page, as of 26 October 2026. The page metadata shows it was last changed on 21 September 2026.

GA means generally available: a finished release, not a preview. TBD means Redis has not set a date yet. Redis 7.0 is not in this supported versions table at all.

The difference is how long a minor version keeps getting fixes. Standard releases get a short window tied to the next release. Extended releases get 5 years from their own release date.

Here is the policy wording from the official page, quoted exactly. Standard releases "receive security updates and critical bug fixes for 6 months after the following minor version is released."

Extended releases "receive security updates and critical bug fixes for 5 years after their release date." Notice the scope: security updates and critical bug fixes, not every small bug.

Which releases are which also follows a rule. Standard means the first release in a major series, like 8.0, and the in-between minors, like 8.4 and 8.6. Extended means the second minor, like 8.2, and the final minor of a series.

An everyday picture helps. Think of Extended releases as the main bus routes a city promises to run for years, and Standard releases as temporary routes. A temporary route runs until a newer route opens, plus a few months.

Where the picture breaks: a bus route that stops running is obvious. A Redis version past end of life keeps working perfectly, so nothing warns you that fixes have stopped.

One warning: the printed dates do not always match the 6-month rule. Plan by the date in the table, not your own arithmetic, and recheck the page before each planning cycle. The engineer section shows where the two disagree.

If you are on 8.6 or 8.8, do not move down to 8.2. Their saved data files use format numbers 13 and 14, and 8.2 reads only up to 12. A later section explains this number.

Redis 8.0 has had no new release since 8.0.6 on 23 February 2026. Every other line we checked shipped several security releases between May and September 2026.

We checked this in the release notes file inside each tagged release on GitHub. We also read the 8.0 branch history: its last commit is the 8.0.6 release, dated 22 February 2026.

The May batch matters most. On 5 May 2026, Redis 8.2.6 fixed five CVEs. A CVE is a public ID number for a security hole. In its main GitHub repository, Redis also published a security advisory, an official notice, for three of them.

Those three advisories put 8.0 inside the affected range, and each lists the patched version as TBD. As of 26 October 2026, no 8.0 release fixes them.

Beginners can skim the table below. The point is the second column: every row includes 8.0. A use-after-free is a bug where Redis keeps using memory it has already freed, which an attacker can sometimes steer.

All three advisories say the bug may lead to remote code execution: an attacker running their own code on your server. Each needs a logged-in user. If your Redis has no password, anyone who can reach its port counts as logged in.

An ACL, Redis's access control list, sets which commands each user may run. A password and tight ACL rules lower the risk, but they do not remove it.

Ask the running server with INFO server and read redis_version. Running redis-server --version on a machine only tells you which binary file is installed there, not which one is running.

# The binary installed on this machine
redis-server --version

# The server that is actually running (add -h, -p and auth for a remote server)
redis-cli INFO server | grep -E '^(redis_version|redis_mode|executable):'

This is what we got on a Redis 8.0.6 server built from the official 8.0.6 tag on Ubuntu 24.04. We shortened the executable path. Your build ID and path will differ.

Redis server v=8.0.6 sha=f49e5cb2:0 malloc=jemalloc-5.3.0 bits=64 build=87b5fa521583cb81

redis_version:8.0.6
redis_mode:standalone
executable:/path/to/redis-8.0.6/src/redis-server

If redis_version starts with 8.0, you are on the line with the 1 December 2026 end date and the unfixed advisories above.

For most teams, 8.2 is the better target from 8.0. It is supported until 1 September 2030, and it writes the same data-file format as 8.0, so in our test you could roll back.

The newest line, 8.10, has every feature added since 8.2. But it is a Standard release with no end date yet, and you cannot roll its data files back to 8.2 or 8.0.

The data file here is the RDB file. It is a snapshot: one file, usually dump.rdb, holding a copy of all your data at one moment. Redis reads it at startup to get your data back.

The RDB format version is a number in the first bytes of the dump.rdb file. A Redis server refuses any RDB file with a number higher than its own. Check your own file with the command below.

head -c 9 dump.rdb; echo
# Redis 8.0.6 and 8.2.10 wrote: REDIS0012
# Redis 8.10.2 wrote:          REDIS0015

Redis 8.2 adds a few things over 8.0, listed in its release notes. Examples are the stream commands XDELEX and XACKDEL, new BITOP operators and the CLUSTER SLOT-STATS command for per-slot metrics.

You have two paths. With one server, stop 8.0, start 8.2 on the same data files and check the keys. With a replica, bring up 8.2 as a replica, let it copy the data, then switch the app to it.

Path A: replace the binary and restart on the same files

Redis saves data in the RDB snapshot, and often also in an AOF, the append-only file. The AOF is a log of every write that Redis replays after a restart. In our 8.0.6 test it lived in a folder called appendonlydir.

This path takes a short outage, about as long as Redis takes to load your data. Your current 8.0 log shows that time on the line containing "DB loaded from".

1. 1

   Read the 8.2 release notes

   Look for changed commands you use. One example: 8.2.7 reverted a SCAN filter order change that 8.2 had introduced.

2. 2

   Get the 8.2 binary

   Pin an exact patch version, not just "8.2", in your package, image tag or build. As of 26 October 2026 the newest is 8.2.10.

3. 3

   Stop 8.0 with SHUTDOWN SAVE

   SHUTDOWN SAVE writes a final snapshot even when automatic saving is off. In our test, plain SHUTDOWN with saving and AOF off wrote no file at all. Never kill the process.

4. 4

   Back up the stopped files

   Copy dump.rdb and the whole appendonlydir folder somewhere safe, plus the 8.0 binary. Copying after the stop means nothing changes while you copy.

5. 5

   Start 8.2 with the same config and data folder

   Use the same port and config file, so the app needs no change.

6. 6

   Check the version and the data

   INFO server should show redis_version:8.2.10. Compare DBSIZE, the key count, with the number you saw on 8.0, and read a few known keys.

If you need a backup while 8.0 is still running, use BGSAVE and wait. BGSAVE returns at once, so copy the file only when INFO persistence shows rdb_bgsave_in_progress:0 and rdb_last_bgsave_status:ok. SAVE also works, but it blocks every client until it finishes.

Path B: add an 8.2 replica and switch over

A replica is a second Redis server that keeps a live copy of the primary's data. This path keeps downtime to the switch-over itself, the moment your app starts writing to the new server.

It suits the delivery app, which cannot drop OTPs or sessions at lunchtime. The app already has an 8.0 replica, so you can upgrade that replica with Path A and use it as the 8.2 server below.

Step 3 below compares replication offsets. An offset is a running count of replication bytes: the primary shows master_repl_offset and the replica shows slave_repl_offset. When both match, the replica has every write the primary accepted.

1. 1

   Start 8.2 as a replica

   Run REPLICAOF with the 8.0 primary's host and port. If 8.0 uses requirepass, set masterauth first, plus masteruser for an ACL user; without it our replica stayed at master_link_status:down.

2. 2

   Wait for the copy

   Wait until INFO replication on 8.2 shows master_link_status:up. Compare DBSIZE on both servers as a quick sanity check, and read a few keys that matter.

3. 3

   Pause writes and match offsets

   On 8.0, run CLIENT PAUSE 10000 WRITE to hold writes for up to 10 seconds; the pause only needs to cover steps 3 and 4. Wait until master_repl_offset on 8.0 equals slave_repl_offset on 8.2.

4. 4

   Promote 8.2, then point 8.0 at it

   Run REPLICAOF NO ONE on 8.2. At once, set masterauth on 8.0 if 8.2 has a password, plus masteruser for an ACL user, and run REPLICAOF on 8.0 pointing at 8.2.

5. 5

   Switch the app

   Point the app's Redis address at 8.2 straight away. Writes sent to 8.0 from step 3 on are not applied: they fail with a READONLY error, so make sure the app retries failed writes.

6. 6

   Retire 8.0 after a quiet period

   Until then, 8.0 is your rollback copy. Do not start using commands that are new in 8.2 while it is still running.

Why step 4 comes before the app switch: in our test, a write that reached 8.0 after promotion was wiped when 8.0 synced from 8.2. With 8.0 already a replica, a late writer gets a READONLY error instead. In our test, a write held by the pause also failed with READONLY when the pause ended, and never reached 8.2.

The catch with the rollback copy: 8.0 cannot run commands that only exist in 8.2, such as XDELEX, XACKDEL or the new BITOP operators. In our test it skipped them with only a log line, and the link stayed up.

If you run Redis Sentinel or Redis Cluster, the same idea applies: upgrade replicas first, then fail over. Check their docs for the exact commands, because we did not test either for this guide.

Both upgrade paths worked on real builds. We built Redis 8.0.6, 8.2.10 and 8.10.2 from their official GitHub tags with make, on Ubuntu 24.04 on 26 October 2026.

On 8.0.6 we turned on AOF and wrote 9 keys shaped like the delivery app's data. They included a string with a 1-day expiry and two hashes with per-field expiries, one set with HEXPIRE and one with HSETEX.

The rest were a list queue, a set, a sorted-set leaderboard, a stream with a consumer group, a HyperLogLog visitor counter and a vector set. Then we stopped 8.0.6 and started 8.2.10 on the same folder.

* Reading RDB base file on AOF loading...
* Loading RDB produced by version 8.0.6
* Done loading RDB, keys loaded: 9, keys expired: 0.
* DB loaded from base file appendonly.aof.2.base.rdb: 0.000 seconds

redis_version:8.2.10
DBSIZE on 8.2.10: 9

What just happened? 8.2.10 found 8.0.6's AOF folder and read the snapshot at its base first. All 9 keys loaded and none expired during loading. The table below shows the other paths, including rollback.

Two limits matter. We built without the BUILD_WITH_MODULES flag, so JSON, search, time series and Bloom filter data were not tested. If you use those, test your own dump.rdb on 8.2 before the real upgrade.

The rollback results cover this data on these two versions only, standalone and without TLS. The release notes do not promise that 8.2 data will always load on 8.0, so keep your 8.0 backup either way.

The refusal comes from one check in the loader. In 8.2.10's src/rdb.c, Redis rejects any file whose version number is above RDB_VERSION. That value is set in src/rdb.h: 12 in 8.0 and 8.2, 15 in 8.10.

Because the table and the 6-month rule disagree for several Standard lines, and the page does not explain why, as of 26 October 2026. The arithmetic below uses GA dates from the release notes. These are our calculations, not Redis dates.

For 8.0, the releases stopped close to the rule's end. Its last release, 8.0.6 on 23 February 2026, was a security fix 19 days after the rule's 4 February date. 8.0 has had none since.

For 8.4 it is the reverse. It got a security release on 17 September 2026, about five weeks after the rule's 10 August end. Plan by the printed table, but do not count on fixes that the releases do not show.

Not directly. The 1 December 2026 date is for Redis Open Source that you run yourself. Managed services such as ElastiCache, Redis Cloud and Upstash set their own versions and support windows, so check your provider.

Redis's own paid product shows how different the dates can be. The Redis Software lifecycle page lists its 8.0 cluster version with end of life on July 31, 2028. That is a different product from Redis Open Source 8.0.

Valkey is a separate fork of Redis with its own version numbers and release policy. A Valkey server is not Redis Open Source, and this deadline does not apply to it.

Linux distributions are another case. Ubuntu 24.04 ships Redis 7.0.15 from its universe component, and Ubuntu decides how it patches that package. Redis 7.0 is not in the redis.io table, so check Ubuntu's security notices for it.

Interviewers want to hear that you plan around data safety and rollback, not just the new version number. Use this frame and fill it with the delivery app's numbers.

1. 1

   State the deadline and the reason

   Redis 8.0 loses security fixes on 1 December 2026 and already has unfixed advisories. The target is 8.2, an Extended release supported to 2030.

2. 2

   Name what is at risk

   Sessions and OTPs must not vanish mid-login. The order stream and its consumer groups must survive the move.

3. 3

   Pick the path

   Use a replica-based rolling upgrade, so only the switch-over pauses writes. Bound the pause with CLIENT PAUSE and a timeout you choose.

4. 4

   Define the checks

   Match replication offsets before promoting, then watch error rates and latency. Use INFO server to prove the version.

5. 5

   Keep a rollback that keeps writes

   Make the old 8.0 server a replica of 8.2 straight after promotion, and avoid 8.2-only commands until it is retired. 8.2 shares RDB format 12 with 8.0.

6. 6

   Close with the follow-up

   Put the redis.io table and the Redis security advisories on a calendar reminder. Plan later jumps to newer lines as separate changes.