Category: Databases
Managed Valkey: the open alternative to Redis, in your account
The Redis-compatible in-memory store maintained by the Linux Foundation under a BSD licence, installed or migrated in your account, with compatibility checked before anything changes.
- Where it runs
- In your account, in your name
- Backups
- With tested restores
- Updates
- Planned and documented
- Licence
- Open source, BSD 3-Clause
In short
Valkey is an open source in-memory key-value store under a BSD licence, born in 2024 as a fork of Redis under the Linux Foundation. It speaks the same protocol, so most applications work unchanged. We install it in your account or migrate your current Redis, review clients and modules, set up replicas and backups and keep it up to date.
What do we take care of?
Valkey is run just like Redis: persistence, replicas, memory and backups. We cover that in detail in managed Redis and Valkey. This page is about what changes when you choose Valkey or migrate to it:
Inventory
Source version, commands, Lua scripts, modules and clients that touch your current Redis.
Compatibility
Application tests against Valkey in a separate environment, with the same data.
Migration
Live replication, an RDB backup or letting the cache fill up naturally, depending on the case.
Replicas
Sentinel or cluster mode, just as with Redis, with failover tested.
Metrics
A compatible Prometheus exporter and alerts for memory, replication and evictions.
Versions
Keeping track of Valkey releases, which now add features of their own.
How do we migrate from Redis to Valkey?
The method depends mainly on the Redis version you are starting from and on whether the data can be lost:
| Situation | How we do it | Downtime |
|---|---|---|
| A cache that can be rebuilt | We point the application at Valkey and let it fill up | None, just more load on the database for a while |
| Redis 7.2 or earlier, with sessions or queues | Valkey as a replica of the current Redis and a controlled failover | Seconds, while the connection switches |
| Redis 7.4 or 8 | Live key copy with a migration tool and a check of the counts | Short, in an agreed window |
| Provider’s managed service | Engine change from within the service when it allows it | Depends on the provider; we rehearse it first on a copy |
Before production, the application runs its tests against Valkey with a copy of the data. And we leave the way back ready: the old Redis stays available until everything works.
What problems do we come across in a migration?
- New Redis commands that the application started using after the fork and that Valkey does not have or implements differently.
- Redis Stack modules that nobody remembered, such as search or JSON.
- Backups that will not load: a persistence file from a recent Redis that Valkey does not recognise.
- Very old clients that check the server name or version and get confused.
- Monitoring tied to Redis: dashboards and alerts that depend on specific INFO fields.
- No way back: the original Redis switched off before checking that everything works.
Why does Valkey exist?
Up to version 7.2, Redis had a BSD licence. In 2024 the company behind it changed it to a dual licence, RSALv2 and SSPLv1, neither of which is open source by the OSI’s definition. A few days later, former maintainers and several companies created Valkey from Redis 7.2.4 under the Linux Foundation, with the same BSD licence as before. Later on, Redis 8 added AGPLv3 as an open licence option. Since the fork, the two projects have moved forward separately and each adds features of its own, so full compatibility is that of the starting version.
Who is it for?
- A company whose policy requires open, permissive, OSI-approved licences for everything that runs in production.
- A team on AWS, Google Cloud, DigitalOcean or OVHcloud whose managed caching service already offers Valkey as the main option.
- Anyone starting from scratch with caching, queues or sessions and not relying on Redis-specific modules.
If your application uses features or modules specific to Redis 8, staying on Redis is a reasonable decision and we manage it the same way. The metrics end up in monitoring with Grafana and Prometheus.
Where do we set it up?
In your account, with the provider you already use or the one that fits best. If the data has to stay in the EU, Hetzner and OVHcloud are the European options.
Providers we set it up on
- Hetzner
- AWS
- Google Cloud
- DigitalOcean
- OVH
- Own server
| Provider | How we set it up | Things to bear in mind |
|---|---|---|
| Hetzner | Cloud servers with Valkey and Sentinel on three machines and a private network, with RDB backups to Hetzner Object Storage. | No managed cache: we set up replication, failover and backups ourselves. |
| AWS | ElastiCache for Valkey, or EC2 with Valkey and Sentinel if you need something the service does not allow. | The move from ElastiCache for Redis OSS to Valkey is done from within the service; we plan it and check the client versions. |
| Google Cloud | Memorystore for Valkey, with cluster mode if the data does not fit on one node. | |
| DigitalOcean | Managed Caching for Valkey, or Droplets with Valkey and Sentinel. | |
| OVH | Managed Valkey from OVHcloud Public Cloud, or instances with Valkey set up by us. | |
| Own server | Valkey on your servers or virtual machines, with Sentinel on three machines and backups to external S3 storage. |
What is included
- Valkey in your cloud account or on your servers, or your provider's managed service for Valkey if it is a better fit.
- An upfront inventory of what your Redis uses: version, commands, modules, Lua scripts and client libraries.
- Migration from Redis by live replication or from a backup, depending on the source version.
- Application tests against Valkey in a separate environment before touching production.
- Replicas with Sentinel or cluster mode, persistence chosen by use and maxmemory tuned.
- Per-application ACL users, TLS and access only from the private network.
- Metrics in Prometheus and alerts for memory, evictions, connections and lagging replicas.
- RDB backups off the server, a tested restore and upgrades one replica at a time.
Frequently asked questions
Do we have to change our application code to move to Valkey?
Usually not. Valkey uses the same protocol and the same commands as Redis 7.2, so the usual client libraries connect without changes. What we check is whether you use commands or data structures added in Redis versions after the fork, or modules that do not exist in Valkey.
Can we migrate from Redis 7.4 or 8?
Yes, but with more care. Those versions evolved on their own and changed the format of the persistence files, so restoring their backup into Valkey does not always work. In that case we copy the keys live with a migration tool or let the cache fill up on its own, and first check which new commands the application uses.
Does Valkey have the Redis modules, such as search or JSON?
Valkey has its own modules, maintained by the project, for some of those functions, but they are not the same as Redis Stack and do not always have the same interface. If you depend on a particular module, we test it before proposing the change; sometimes the sensible thing is to stay on Redis.
Why are cloud providers moving to Valkey?
Because Valkey keeps the BSD licence Redis had until 2024 and is governed by a foundation with several companies involved, including large cloud providers. That is why AWS, Google Cloud, DigitalOcean and OVHcloud offer it as a managed service. For you, the practical effect is that it is usually the default option in their caching services.
Tell us about your case
In a free 20-minute call we look at where you are and where to start. No commitment.
Official documentation consulted
The technical details on this page are based on:
Reviewed on