Kvindo™ Cloud Docs
A Valkey Replication deployment — the NON-cluster tier: one primary and N replicas sharing one key space, with automatic failover driven by dedicated Sentinel VMs. Unlike the sharded Valkey cluster, multi-key operations, MULTI/EXEC and SELECT all work here, which is what Celery/Sidekiq-style brokers need. Alongside it: the shared Parameter Set that owns the tuning, and a Valkey User attached to this deployment rather than to a cluster. Assumes the Networking example's demo network is already applied. kc resolves parametersSetId and valkeyReplicationId by name because they sit directly on spec, but not instances[].vpcSubnetId (it is nested inside a list) — so the subnet's real ID is looked up and captured into a shell variable first, making the whole block directly runnable.
Once reconciled, read the credential-free connection URI a client would actually use: kc get valkey-replication main-repl -n demo -o json | jq -r .status.connectionUri. Treat it as a snapshot — after a Sentinel failover it lags the real topology for a few minutes.
Two rules the service enforces and a copy-paste will not tell you: sentinelInstances is required and accepts 1 or 3 Sentinels, never 2 (a majority of two survives no failure at all) — Sentinel is mandatory, there is no sentinel-less shape — and every node of one deployment, Sentinels included, must be reachable from the others inside one VPC.
Resource docs
More in this section