Published

Valkey

Open-source in-memory key-value store under the Linux Foundation, forked from Redis OSS 7.2 and compatible with its clients and data files. Fits as the cache, session store or job queue that other self-hosted apps need.

Resources by load level

What the app itself needs at each level, next to what we recommend for a server that runs only this app.

Level	What it means	App requirements	Recommended
LightEstimate	Up to 0.5 GiB of keys in memory (about 6 million small string keys): cache, sessions or a job queue for one to three apps, RDB snapshots.	1 vCPU · 1.25 GiB RAM · 1.25 GiB disk	1.32 vCPU · 3 GiB RAM · 10.753 GiB disk
MediumEstimate	Up to 4 GiB of keys in memory (about 50 million small string keys), shared by several apps with steady writes, RDB snapshots.	2 vCPU · 10 GiB RAM · 8.25 GiB disk	2.52 vCPU · 13.5 GiB RAM · 18.803 GiB disk
HeavyEstimate	Up to 16 GiB of keys in memory (about 200 million small string keys), write-heavy apps with I/O threads on, RDB snapshots of a large dataset.	4 vCPU · 40 GiB RAM · 32.25 GiB disk	4.92 vCPU · 49.5 GiB RAM · 46.403 GiB disk

Recommended = app requirements + system baseline + safety headroom, under sizing policy 2026.10.0. Options stay at their defaults. “Estimate” means the sources give no number for that case, so it is worked out from them by the method stated under Components. How the numbers are built

Size it in the Stack Sizer

Ready-to-run files

Support level Supported

Compose template from the official sources; not yet verified by a run.

Create docker-compose

Components

What each component needs at each load level, before baseline and headroom.

vCPU / GiB RAM / GiB disk
Component	Light	Medium	Heavy	Sources
Valkey (cache)	1 / 1.25 / 1.25	2 / 10 / 8.25	4 / 40 / 32.25	[10][13][14][18][23][25]

How the estimates are worked out

Valkey · Light: No upstream sizing table. RAM: maxmemory at about 80% of the memory given (docs: 8 to 9 of 10 GB), so 0.5 GiB of data → 0.625 GiB used; a save of a write-heavy dataset can need up to 2× (fork copy-on-write) → 1.25 GiB. vCPU: commands run on one main thread. Disk: Image 44,768,058 B compressed (0.042 GiB) + 117,767,168 B unpacked (0.110 GiB), both kept by the containerd store = 0.151 GiB. 0.151 + 0.5 GiB dump.rdb + 0.5 GiB temporary file while a save runs → 1.25.
Valkey · Medium: Same method as light. RAM: 4 GiB of data → 5 GiB used at maxmemory 80%, ×2 for copy-on-write during a save or AOF rewrite → 10 GiB. vCPU: the main thread plus the forked child that writes a 4 GiB snapshot on a second core → 2. Disk: 0.151 GiB image + 4 GiB dump.rdb + 4 GiB temporary file while a save runs → 8.25.
Valkey · Heavy: Same method. RAM: 16 GiB of data → 20 GiB used, ×2 for copy-on-write → 40 GiB. vCPU: io-threads 3 (the main thread plus two I/O threads; valkey.conf suggests 2 or 3 on four cores and a spare core) and one core for the save child → 4. Disk: 0.151 GiB image + 16 GiB dump.rdb + 16 GiB temporary file while a save runs → 32.25.

Ports

Public ports are meant to be reached from outside the stack, usually through a reverse proxy; internal ones stay on the stack's own network.

Component	Port	Exposure	Purpose	Sources
Valkey	6379/tcp	Internal only	Valkey client connections (RESP); keep on the internal Docker network or on loopback	[1][2][4]

Every port in the catalog, with conflicts between apps

User and permissions (UID/GID)

The user each container's process runs as, and the paths it writes to. A bind mount for one of these paths must be writable by that UID:GID.

Component	UID:GID	User	Starts as root	Writes to	Sources
Valkey	999:999	`valkey`	Yes, prepares its directories, then drops to this user	`/data`	[2][3][4]

Storage growth

How much each component's data grows per month at each load level, on top of the disk in the profile. A value marked Assumption is ANAROQ's stated assumption, not a figure from the sources; the notes say what it rests on.

GiB per month
Component	Light	Medium	Heavy	Sources
ValkeyDerived	0	0	0	[10][18]

What the growth figures rest on

Valkey: The data lives in RAM. dump.rdb is a snapshot that each save replaces, so the disk follows the dataset, which the preset caps; more data means a larger preset, not monthly growth. With AOF on, the files can reach twice their size after the last rewrite (auto-aof-rewrite-percentage 100) before a rewrite.

Upgrade and rollback

How to move to a new version safely, and how to go back if it fails.

Back up first

Run docker compose exec valkey valkey-cli SAVE (valkey-cli takes the password from VALKEYCLI_AUTH), then copy /data/dump.rdb, and /data/appendonlydir if AOF is on, off the server. [6][10][18]

Upgrade steps

Back up dump.rdb first (see backup). Then set the new pinned tag in the Compose file and run docker compose pull and docker compose up -d. On stop, Valkey saves the dataset, and it loads dump.rdb at start. [2][10][13]
From 8.x to 9.x, read the 9.0 and 9.1 release notes first. Valkey 9.0 writes RDB version 80 (8.x uses 11), so keep the 8.x dump.rdb until the new version has proved itself. [19][20][21]
Moving from Redis OSS 7.2 or earlier: run SAVE on Redis, stop it, copy its dump.rdb into the Valkey /data volume and start Valkey. Data files of Redis CE 7.4 and later cannot be loaded. [17]
Upgrading without downtime needs a second instance as a replica that is then promoted; this template runs a single instance, so plan for a short restart. [13]

Roll back

Within one major version, pin the previous tag and recreate the container. Back from 9.x to 8.x: stop the stack, put the pre-upgrade dump.rdb back in /data, pin the old tag and start it; writes made after the upgrade are lost. [10][19]DerivedUpstream documents no downgrade. rdb.h maps RDB 11 to Valkey 7.x and 8.x and RDB 80 to 9.0, and raises the version only for changes that are not backward compatible, so an 8.x server is not expected to load a file saved by 9.x.

Known breaking changes

In 9.1.2: ACL fixes: HGETEX needs write permission and MOVE and COPY check access to the current database. HPERSIST, HTTL, HPTTL, HEXPIRETIME and HPEXPIRETIME return a syntax error without FIELDS. sanitize-dump-payload is a no-op: payloads are always validated. [20]
In 9.0.0: New RDB format version 80 (Valkey 7.x and 8.x use 11), so a dump.rdb saved by 9.x does not go back to 8.x. Unauthenticated clients now get NOAUTH before any unknown-command or arity error. [19][21]DerivedThe NOAUTH order is in the 9.0.0 behavior changes (#1475). The RDB version is not in the release notes; it comes from the version map in rdb.h at 9.1.2.
In 8.0.0: Rebranding: the default pidfile is valkey.pid and syslog-ident is valkey, and process titles and log lines say valkey. Nested MULTI or WATCH aborts the transaction, and repl-backlog-size grew from 1 MB to 10 MB. [22]
In 7.2 (from Redis): Valkey is compatible with Redis OSS 7.2 and earlier (protocol, configuration, RDB and AOF), but not with data files of Redis CE 7.4 and later. INFO still reports redis_version:7.2.4; check valkey_version instead. [17]

Limits

The whole dataset lives in RAM. No maxmemory is set, so Valkey grows until the container or host runs out of memory. Add --maxmemory (about 80% of the RAM given) and a --maxmemory-policy to VALKEY_EXTRA_FLAGS: the default noeviction refuses writes when full, allkeys-lru suits a pure cache. [1][13][14][15][18]
Snapshots fork the server. Set vm.overcommit_memory=1 on the host, or a save can fail with a fork error when free RAM is below the dataset size; Valkey also advises turning off Transparent Huge Pages. Both are host settings that a Compose file cannot set for the container. [13][14][26]
The template keeps RDB only: a snapshot after 1 hour and 1 change, 5 minutes and 100, or 1 minute and 10,000, so a crash loses the latest writes. For queues, add --appendonly yes; on a server with data, run CONFIG SET appendonly yes first, or the restart starts from an empty AOF. [1][10][18]
On docker compose stop Valkey saves the dataset before it exits, but Compose kills the container after 10 seconds by default. With a large dataset, add a longer stop_grace_period to the service, or the writes since the last snapshot are lost. [2][26]
One standalone server: no replica, Sentinel or cluster, so a host failure means downtime and a restore from the last copied snapshot. [10][13]

Security

The image turns protected mode off and sets no password, so the template always sets one (requirepass). Keep 6379 off the internet: the publish-loopback option uses 127.0.0.1 only, and without TLS the password and data cross the network in clear text. [1][2][5]
requirepass is one shared password for the default user. For a user per app with limited commands and keys, use ACLs (ACL SETUSER). Keep the password long: Valkey can test many passwords per second. [5][16][18]
The password is in the container environment (VALKEY_EXTRA_FLAGS, VALKEYCLI_AUTH), so valkey-cli inside the container connects without -a. Do not pass it with -a: the docs advise VALKEYCLI_AUTH as the safer way. [3][6][7]
9.1.2 is a security release: it fixes an unauthenticated use-after-free of the Lua interpreter (GHSA-fq2f-crmw-q97r). Stay on the newest patch release of your line. [20]

Backup

Copy /data/dump.rdb on a schedule (the docs: hourly copies for 48 hours, daily ones for a month or two) and move one off the server every day. Copying while Valkey runs is safe: a new snapshot replaces the file by an atomic rename. [10]
With AOF on, copy /data/appendonlydir only while no rewrite runs: set auto-aof-rewrite-percentage 0, check aof_rewrite_in_progress is 0 in INFO persistence, copy, then restore the setting. [10]
To restore, stop the stack, put dump.rdb in the /data volume and start Valkey; it loads the file at start. With AOF on, the AOF wins over dump.rdb, so restore appendonlydir as well. [10][17]