A Valkey Replication is a managed, non-cluster Valkey deployment: exactly one primary plus N replicas over a single key space. Because every node holds the same key space, multi-key operations (MGET, MSET), MULTI/EXEC, Lua scripting and SELECT 0..15 all work. The sharded Valkey Cluster product cannot serve this: its own documentation states that Celery/Sidekiq-style brokers do not work in cluster mode and that no configuration changes fix it — those frameworks are exactly who this tier exists for.

Key concepts

• Exactly one primary plus N replicas — spec.instances holds 2 to 6 entries (1 replica minimum, 5 maximum); the primary is the single entry whose role is primary. There is no sharding, so the whole dataset must fit in one VM's RAM

• Failover is owned by Valkey Sentinel, never by the platform — Sentinel promotes a replica autonomously on the VMs themselves. The only platform-initiated switch is the declarative manual failover below

• Sentinel is mandatory, with no co-located option on purpose — sentinelInstances is required: exactly 1 or 3, never 2. There is no sentinel-less shape. A Sentinel sharing a VM with a data process loses its timer interrupt under exactly the load that makes failover necessary, enters TILT, and then stops acting and votes no while SENTINEL CKQUORUM still reports OK

• One or three Sentinels, never two — a promotion needs a majority of the voters, and a majority of two survives no failure at all, so exactly two Sentinels is rejected outright

• sentinel_redundancy is single-failure at three Sentinels and none at one — a single Sentinel is automated recovery, not high availability: it removes the human from the common case, but losing it removes failover entirely until it is restored. A one-Sentinel deployment also requires at least two replicas

• A manual failover is declarative and consumed once — set spec.requestedPrimaryInstanceId to the instance you want promoted (requires dedicated mode); the platform performs a graceful demote-then-promote, re-points the remaining replicas and clears the field. There is no automatic failback: a failback is simply a second failover

• Sentinel endpoints are reachable only from inside the VPC or over VPN — Sentinel VMs never receive a public IP, so a client outside the network has no discovery path at all

• status.primaryEndpoint is a snapshot, not a stable address — after a failover it can still point at the demoted node until the next reconcile, and a client that treats it as a fixed write address gets READONLY. Use Sentinel discovery in your client library instead

• Tuning lives in the shared parameter set, not in this spec — maxmemory*, io-threads, appendfsync, min-replicas-max-lag, databases, rdb-enabled and the AOF switch have no field here; they are owned by the Parameter Set, the very same resource the sharded cluster uses

Tuning

This spec carries no tunable field at all — not maxmemory, io-threads, appendfsync, min-replicas-max-lag, not the AOF switch, and not databases or rdb-enabled either. Every one of them is a valkey.conf directive, so the shared Valkey Parameter Set owns them — the same resource the sharded cluster uses, because tuning belongs to a Valkey estate rather than to one product.

Examples

One primary, one replica and one Sentinel, on a single subnet, with tuning taken from an existing parameter set.

Terraform

Python SDK

kc CLI

Related pages

Resource docs

• Parameter Set resource docs
• Valkey User resource docs
• VPC Subnet resource docs

Examples

• CLI Valkey Replication example
• Terraform Valkey Replication example
• Python SDK Valkey Replication example

More in this section

• Valkey Cluster