Okay friend, pull up a chair. We need to talk about Valkey — the open-source, free-forever, Redis-compatible key-value store that has quietly become the default cache and session store for serious Linux servers in 2026. If your brain just slid off the words “key-value store,” don’t worry. By the end of this post you’ll know exactly what Valkey is, why it exists, why our build of it on deb.myguard.nl is worth using over the one in stock Debian, and how to install it in under sixty seconds. No prior IT experience required. Yes, really.
What is Valkey, in plain English?
Imagine your website is a busy coffee shop. Every time someone orders a latte, your barista (the database) has to grind beans, steam milk, foam, pour, and add the little heart on top. That’s slow. Now imagine you keep a tray of pre-made lattes on the counter — when someone orders one, you just hand it over. That tray is a cache, and Valkey is the tray. It holds frequently-needed data in memory so your apps don’t have to go grind the beans every time.
Technically: Valkey is an in-memory, network-accessible key-value database. You give it a key (“user:42:cart”), it gives you back the value (“3 lattes, 1 muffin”). It’s blisteringly fast — a single instance comfortably handles 100,000+ operations per second on a modest VPS. It speaks the Redis wire protocol, so anything that talks to Redis talks to Valkey unchanged. Drop it in, walk away.
Wait — isn’t this just Redis?
This is where it gets juicy. In March 2024, the company that owns Redis suddenly changed the licence from open-source BSD to a more restrictive “source-available” licence (SSPL / RSALv2). Translation: free to use, but legally hostile to anyone running it as a service for customers. The open-source community did what the open-source community always does when this happens — they forked.
Within a week, the Linux Foundation, AWS, Google Cloud, Oracle, Ericsson, and Snap had launched Valkey: a clean fork of the last freely-licensed Redis (7.2.4), with the original BSD-3-Clause licence intact, governed by a vendor-neutral foundation. Debian, Ubuntu, Fedora, and Alpine all switched their default “redis” package to Valkey within months. AWS ElastiCache replaced Redis with Valkey on managed services. By the time Redis tried to walk back the licence change in 2025, Valkey already had more contributors than Redis itself.
So when you install valkey in 2026, you’re not getting some hobbyist experiment. You’re getting the actual, mainstream, foundation-backed continuation of Redis — with bug fixes, performance work, and security patches that Redis never received. It’s Redis, minus the corporate drama.
What people actually use Valkey for
- WordPress object cache. Plugins like Redis Object Cache, W3 Total Cache, and LiteSpeed Cache all talk to Valkey unchanged. The result: 50-90 % fewer database queries on every page load, and a noticeably snappier admin dashboard. If you’ve ever clicked “Save” in WordPress and waited an awkward two seconds, Valkey kills that.
- Session storage. PHP, Node.js, Rails, Django — all of them can keep user sessions in Valkey instead of files. That means session data survives across multiple web servers (essential for load balancing) and doesn’t fill up your disk with millions of one-kilobyte files.
- Rate limiting. “Don’t let this IP make more than 60 API requests per minute.” Valkey does this in a single atomic operation. Cloudflare-grade rate limiting on your own server, basically free.
- Job queues. Background tasks (sending email, processing uploads, generating thumbnails) go onto a Valkey list, a worker pulls them off. Sidekiq, BullMQ, RQ, Laravel Horizon — they all run on Valkey.
- Leaderboards and counters. Sorted sets in Valkey let you maintain “top 100 most active users today” with one command per update. Used by every gaming site you’ve ever loved.
- Pub/sub messaging. A lightweight message bus between microservices, without dragging in Kafka or RabbitMQ.
Why use our Valkey package and not the stock Debian one?
Debian’s Valkey package is fine. It’s also frozen — once Debian 13 (Trixie) shipped, the Valkey version baked into it is the version you’ll have for the next two years unless you do something about it. Meanwhile upstream Valkey keeps shipping releases with real performance wins and security fixes every few weeks.
Our build at deb.myguard.nl tracks upstream Valkey 9.1.0 (the current stable release as of May 2026) and rebuilds within hours of every new tag. But that’s only half the story — the package itself ships a bunch of operational improvements that the Debian package doesn’t have:
1. Compiled for performance, not lowest-common-denominator
We build Valkey with Link-Time Optimization (LTO), -O3, -fno-plt, and -fno-semantic-interposition. In plain English: the compiler is allowed to inline aggressively across translation units, skip a layer of indirection on every function call, and reorder code for the modern CPUs you’re actually running on. The throughput gain over a stock -O2 build is real — typically 5-12 % on the standard valkey-benchmark SET/GET workload, sometimes more on pipelined operations.
2. Compiled for security, with FORTIFY_SOURCE level 3
Every Debian hardening flag is on (hardening=+all: stack protector, stack-clash protection, RELRO, BIND_NOW, PIE, control-flow integrity) — and we go one further by bumping _FORTIFY_SOURCE from 2 to 3. That enables additional compile-time and runtime checks on memory functions like memcpy, strcpy, and friends. A buffer overflow that would silently corrupt memory becomes an immediate, loud, abort-the-process crash — which is exactly what you want, because a crash is a bug report, but silent memory corruption is a data breach waiting to happen.
3. A fully hardened systemd unit out of the box
Most database services run with way too many privileges. Our valkey-server.service ships with the full systemd sandbox switched on: NoNewPrivileges=true, ProtectSystem=strict, ProtectKernelTunables/Modules/Logs, MemoryDenyWriteExecute=true, RestrictAddressFamilies limited to AF_INET/AF_INET6/AF_UNIX, an empty CapabilityBoundingSet, SystemCallFilter=@system-service, and NoExecPaths=/ (so the daemon literally cannot execute any binary other than itself). If somebody finds a remote code execution in Valkey tomorrow, the blast radius on our package is “they get to run code as the valkey user inside a near-empty namespace with no network families they don’t already have.” On a stock build it’s “they get a shell.”
4. A drop-in /etc/valkey/conf.d/ directory
The main valkey.conf is a 2,000-line conffile and you don’t want to edit it. Every time you do, the next package upgrade fights you over conffile changes. Our package ships an include /etc/valkey/conf.d/*.conf line in the main config, plus an empty drop-in directory. Want to set maxmemory 2gb and switch the eviction policy? Drop a one-line file in /etc/valkey/conf.d/10-memory.conf and reload. Survives upgrades, easy to manage with Ansible/Salt/Puppet, easy to diff in version control.
5. An AppArmor profile (when AppArmor is available)
Belt and braces alongside the systemd sandbox: a Mandatory Access Control profile at /etc/apparmor.d/usr.bin.valkey-server that confines reads to /etc/valkey and writes to /var/lib/valkey / /var/log/valkey / /run/valkey. Loaded automatically on systems that support it, silently skipped in containers that don’t. You get defense in depth on Ubuntu (where AppArmor is on by default) without any breakage on hosts without it.
6. Sane kernel tuning, applied automatically
Valkey emits two warnings on every fresh install on a stock kernel: “vm.overcommit_memory is not set to 1” and “the TCP backlog setting was lowered to 128 because /proc/sys/net/core/somaxconn is set to the lower value.” Annoying, and they actually do affect throughput. We ship /usr/lib/sysctl.d/30-valkey-server.conf that fixes both. Applied automatically by systemd-sysctl on next boot, or by the postinst when you’re inside a Docker container without systemd.
7. A built-in healthcheck binary
We ship /usr/bin/valkey-healthcheck — a tiny wrapper that returns exit code 0 if the server replies to PING, 1 if it doesn’t. Wire it into a Docker HEALTHCHECK, a Kubernetes liveness probe, a Nagios/Icinga check, a systemd watchdog — anything that wants a binary that says “yes the service works” or “no it doesn’t.” Honours the same env vars as valkey-cli (host, port, TLS, auth), so it works regardless of how exotic your deployment is.
8. Works perfectly inside Docker (without systemd or AppArmor)
All of the above is built so the package installs cleanly inside a minimal Debian/Ubuntu container. No hard dependency on systemd, no hard dependency on AppArmor, no failed postinst when those subsystems aren’t around. The systemd unit and the AppArmor profile become inert files — present but not enforced — and the sysctl drop-in is applied at install time instead of at boot. Same package, two deployment models, zero ceremony.
How to install Valkey from our repository
If you haven’t added the deb.myguard.nl repository yet, that takes about ninety seconds — there’s a one-page setup guide that handles the GPG key and APT source. Once that’s in:
sudo apt update sudo apt install valkey-server valkey-tools # Enable on boot (skip inside Docker) sudo systemctl enable --now valkey-server # Check it answers valkey-healthcheck && echo "Valkey is up"
That’s it. You now have a hardened, performance-tuned, foundation-backed Redis replacement listening on 127.0.0.1:6379.
Migrating from Redis: how painful is it?
Pretty close to zero pain. Valkey speaks the same wire protocol as Redis, ships the same commands, returns the same replies. RDB and AOF persistence files from Redis 7.2 load unchanged. The CLI tool is valkey-cli instead of redis-cli, but both are symlinked on most distros, and they accept identical arguments.
Practical migration recipe: stop Redis, copy dump.rdb to /var/lib/valkey/dump.rdb, chown valkey:valkey it, start Valkey, point your app at localhost:6379 instead of wherever Redis was. Done. PHP’s phpredis extension, Python’s redis-py, Node.js’ ioredis, Go’s go-redis — all of them connect to Valkey without a single code change.
A WordPress-specific recipe
Since most readers of this site run WordPress, here’s the exact recipe to turn Valkey into a WordPress object cache. Install Valkey as above, then drop this into /etc/valkey/conf.d/10-wordpress.conf:
maxmemory 256mb maxmemory-policy allkeys-lru save "" appendonly no
That tells Valkey: use up to 256 MB of RAM, evict the least-recently-used keys when full, and don’t bother persisting to disk (it’s a cache — if it dies, WordPress just rebuilds it from MySQL). Restart with systemctl restart valkey-server, install the Redis Object Cache plugin in WordPress, click “Enable Object Cache.” Done. Your admin dashboard just got 3-5× faster, and the MySQL load on your server dropped by half.
Frequently Asked Questions
Is Valkey really free? Like, free-free?
Yes. BSD 3-Clause licensed, governed by the Linux Foundation, with no contributor licence agreement that hands rights to a corporation. You can use it commercially, modify it, redistribute it, run it as a service, embed it in proprietary products. The whole point of the fork was to keep it that way permanently.
Should I uninstall Redis if I have it?
Eventually, yes. Both can coexist (different default ports if needed), but there’s no reason to run both long-term. Migrate the data over, point apps at Valkey, then remove the Redis package. If you’re on Debian 13 or Ubuntu 24.04+ you may notice apt already wants to replace Redis with Valkey on the next upgrade — that’s the distribution doing the same migration for you.
How much RAM does Valkey need?
Whatever you tell it. For a WordPress object cache, 128-256 MB is plenty. For a session store on a busy site, 512 MB-1 GB. For a primary database with millions of keys, size it to fit your working set in memory. The base process itself uses about 5 MB — almost nothing. Always set maxmemory; never let Valkey grow unbounded.
Does Valkey lose data if the server reboots?
By default it snapshots to disk every few minutes (RDB persistence) and optionally appends every write to an AOF log for crash safety. You can disable persistence entirely (good for pure caches), enable both (good for primary databases). The trade-off is durability vs. write performance, and it’s a single config flag away in either direction.
Is Valkey faster than Redis?
In raw single-threaded SET/GET, they’re within noise of each other — they share an ancestor. Where Valkey pulled ahead is in multi-threaded I/O (enabled by default in 9.0+, on by default on multi-core systems) and in the steady stream of optimizations the wider contributor base has been merging. On the same hardware, a recent Valkey will out-throughput a Redis 7.2 by 20-40 % on multi-connection workloads. Our build with -O3 and LTO adds a few more percent on top.
What’s the catch?
Honestly, none for most use cases. If you used a Redis Enterprise feature (Redis Stack modules like RedisJSON, RedisSearch, RedisBloom) then those modules were proprietary and aren’t in Valkey core. The good news: Valkey has its own first-party equivalents (valkey-json, valkey-search, valkey-bloom) which are now stable and shipping. We’ll likely add packages for those next.
Related reading
- WordPress NGINX Configuration: PHP-FPM Tuning, FastCGI Cache and Redis (2026 Guide) — the full stack guide that puts Valkey (still named “Redis” in the plugin world) into context for WordPress hosting.
- Database Boost: Free WordPress Database Optimization Plugin — pairs nicely with Valkey object caching to keep MySQL lean.
- How to Add the myguard APT Repository — the ninety-second setup for the repo this package lives in.
- Full package catalogue — every package we ship, with one-line descriptions.
Valkey is the future of self-hosted in-memory caching on Linux. Our build makes it faster, safer, and easier to operate than anything else in the Debian/Ubuntu ecosystem — and it stays out of your way whether you’re running it on bare metal, in a VM, or inside a Docker container. Install once, forget about it for years.