Check against your doze
Checking against doze
Valkey
OfficialSignedIn-memory cache, Redis-compatible.
doze/valkey$ doze add valkey- Newest
- 0.2.1 · 2 Jul 2026
- Needs
- any doze
- Runs
- Valkey 8 – 9
- Platforms
- macOS arm64 · Linux arm64 · Linux x86_64
- Licence
- Apache-2.0
- Source
- doze-modules
Versions
One release resolves. Nothing is ever taken down: a project pinned to any of them keeps working, and doze modules upgrade is the only thing that moves a pin.
Any doze, every release
- valkey 0.2.1Currentany dozeJul 2026. No oldest-doze field, so it runs on every doze, 0.1.0 and up.
The release tool writes the field from the SDK the module was built with, always as three numbers. A doze older than a release's minimum skips it and takes the newest release that fits.
doze 0.1.1 can't read a release's minimum doze. Update doze first, with brew upgrade doze, then run doze modules upgrade.
All releases
| Version | Released | Status | Needs doze | Protocol | Valkey | Platforms | Notes |
|---|---|---|---|---|---|---|---|
| 0.2 | 1 in the index · newest 0.2.1 | ||||||
| 0.2.1 | 2 Jul 2026 | Current | any doze | 1 | 89 | macarmx86 | |
No release matches these filters.
No download counts here: doze sends no telemetry, so nobody, including us, knows how often a release is fetched. Security advisories: none known for any release.
Not in the index
GitHub has older valkey builds than the registry lists. doze only resolves what the signed index names, so these can't land in a doze.lock.
- 0.1.028 Jun 2026. Built before protocol 1 and the signed index (2 Jul).
- 0.2.02 Jul 2026. On GitHub, never listed in the signed index.
- All files on GitHub
Upgrading a project
A project stays on the release in its doze.lock until you move it. Check first; the upgrade takes the newest release your doze can run, verifies it, and rewrites the pin.
$ doze modules upgrade --check$ doze modules upgrade valkeyOn doze 0.1.1, update doze first: it can't read a release's minimum doze. Engine pins never move with a module upgrade.