SYS.DOCS // DOCS

Valkey

Edka provisions Valkey on your cluster for caches, queues, or durable key-value storage. A database runs standalone or as a primary with up to three replicas, with optional automatic failover through Sentinel.

A Valkey database has Overview, Insights, Logs, Backups, and Settings tabs.

Prerequisites

For automatic failover, one schedulable worker node for each data instance, and at least three.
For backups, an Object Storage integration with the Amazon S3 or S3-Compatible provider.
For a Tailscale endpoint, the Tailscale add-on installed on the cluster. For a private load balancer, private networking enabled on the cluster.

Create a database

Open the cluster and select Databases under Workloads. Select Create Database, then pick Valkey.
On General, enter the name and namespace, and pick the version, 9.1.2 (default) or 9.0.2. Set Usage posture to Durable database or Cache-first.
On Resources, set CPU and memory. The defaults are a 10 m CPU request, a 64 Mi memory request, and a 1024 Mi memory limit. CPU limit (m) is empty by default, which means no limit.
On Persistence, pick the Persistence mode and the storage. See Persistence, memory, and storage.
On Security, keep or change ACL auth and the Default user password.
On Replication, pick the Topology. See Replication and automatic failover.
On Placement, pick a Node pool and keep Tolerate node-pool taints on when the pool is tainted.
Review Access and Backup, then select Create Valkey.

The name, the namespace, the choice of Standalone or Primary + replicas, and the storage class of a persistent database are fixed after creation.

Persistence, memory, and storage

Persistence mode is No persistence, RDB snapshots, or RDB + AOF. New databases use RDB + AOF with appendfsync everysec. No persistence is available only for a Standalone database with the Cache-first usage posture. Replication requires persistent storage on every instance.

Usage posture sets the eviction policy. Durable database uses noeviction, so writes fail when the dataset reaches its memory budget. Cache-first uses allkeys-lru.

Dataset memory budget (%) sets maxmemory as a share of the memory limit, from 10% to 80%. The form starts at 50%, which leaves room for snapshots and AOF rewrites. A cache without persistence can use up to 80%.

Storage size (Gi) defaults to 10. It can grow when the StorageClass allows volume expansion. It cannot shrink, and persistent storage cannot be removed.

Changing the persistence mode on an existing database is a maintenance operation. Client connections pause while Edka saves or copies the data, and the database restarts before access resumes. Save it on its own, apart from changes to the version, credentials, ports, storage size, or topology.

Replication and automatic failover

Primary + replicas runs one primary and a Replica count of 1, 2, or 3. Read service, on by default, adds a <name>-read Service for reads from inside the cluster.

Automatic failover lets three persistent Sentinels elect a new primary with a quorum of two. It requires:

ACL auth
a primary and at least two replicas
a separate schedulable worker node for each data instance

Sentinels also spread across separate nodes. Disruption budgets protect planned drains. Applications keep the same service endpoint, but clients must reconnect after a promotion. Writes are accepted only while enough replicas have responded within Max replica lag (s), 10 by default. Replication is asynchronous, so acknowledged writes can still be lost during a failure.

Adding replicas keeps the existing data pods. Before a scale-down removes the current primary, Edka waits for the remaining replicas to catch up and moves the primary. With failover on, save version, port, or credential changes apart from a replica reduction. Failover can be turned on later for a replicated database. It cannot be turned off in place. Restore into a new database to change that.

Connections and TLS

Overview shows the connection details. Inside the cluster, applications connect to the database Service without TLS. The port is 6379 unless you change Port on the Access tab.

External access requires ACL auth. If it was off, turning on External Access turns it on and generates a password. Turning external access on restarts Valkey once to open its TLS listener.

Valkey serves the database hostname’s certificate on a separate TLS listener, and the external endpoint targets that listener. Outside clients use a rediss:// URI with the hostname from Overview. Verified connection shows a redis-py example that verifies the certificate and hostname with the system trust store. valkey-cli --tls checks the chain but not the hostname. See External access.

Turning on external access does not change the address or port that applications inside the cluster use. After changing the Valkey password or port, reapply the apps connected to it. The form does not offer custom ACL users, external secret references, or raw valkey.conf overrides.

Backups

Save an Object Storage integration with the Amazon S3 or S3-Compatible provider.
Open the create form or Settings, then Backup. Turn on the Backups switch and select Backup storage.
Set Interval (hours) from 1 to 168 and Retention (days) from 1 to 365. The defaults are 24 and 7.
Set Workspace (Gi), the temporary volume for the snapshot. It defaults to the memory limit rounded up to Gi.
Save.

The schedule runs inside your cluster on the hour in UTC. A backup starts once the interval has passed since the last successful one, and a failed backup retries at the next hour. Scheduled backups keep running while Edka is unreachable. Edka adds the results to the Backups tab and applies retention when the connection returns. Backup now takes an extra backup. It is available when backups are on, the database is ready, and no other backup is running.

A backup copies an RDB snapshot from the primary into your bucket, under valkey/<organization-id>/<database-id>/backup-<backup-id>/. The storage credentials need to read, write, delete, and list objects, and to create, list, and abort multipart uploads. A backup job has a 24 hour deadline.

Deleting a database removes its backup jobs from the cluster. The snapshots stay in the bucket and on the restore list until their retention ends.

Restore a snapshot

On Backups, select Restore on a completed snapshot.
Enter the New installation name, which defaults to <source>-restored.
Pick the Storage class and the Storage size (Gi). The size must be at least three times the snapshot size.
Select Restore.

To start from the create form, choose the snapshot under Restore an existing backup on the Backup tab. That list includes snapshots from deleted databases. Organization owners and administrators can also select snapshots from other clusters in the organization. The storage integration must still point at the bucket and endpoint that hold the snapshot.

Restore creates a separate database at the snapshot’s Valkey version and leaves the source unchanged. Edka checks the snapshot against its manifest, size, and SHA-256 checksum before loading it, and replicas synchronize from the restored primary. The memory limit must be at least 1.25 times the memory the source used when the snapshot was taken.

A database restored from Backups gets a new password and starts with ACL auth on, RDB + AOF persistence, default placement, external access off, and backups off.

Restore recovers the selected RDB snapshot. Writes made after that snapshot are not included, and there is no point in time recovery for Valkey.

To test a backup, restore it into a new database, check the data, and delete the test database.

Monitoring and alerts

The Valkey metrics exporter is always on. Insights charts operations, keys, CPU, and memory, and reports connections, cache hit ratio, evictions, and the memory limit. The key count comes from the primary. A warning appears when a replica is disconnected or still synchronizing. With failover on, Overview also shows how many of the three Sentinels are ready. History needs VictoriaMetrics installed on the cluster.

With VictoriaMetrics installed, open Observability, then Alerts, then Packs, and install Valkey. Its ten editable rules cover availability, memory and connection pressure, rejected connections, replica connectivity and traffic, RDB and AOF failures, and missing core metrics. Installing packs needs the Standard plan or higher. See the Valkey alert pack for thresholds and coverage.

Troubleshooting

Storage does not grow. The StorageClass must allow volume expansion. Otherwise, restore into a new database with larger storage.
Settings cannot be saved. Edka rejects a save while a scheduled backup is running. With failover on, a maintenance change also waits until all three Sentinels are ready.
A scheduled backup did not start. The vk-backup-<database-id> CronJob in the database namespace runs the schedule. Check its Jobs:
Terminal window
```
kubectl get cronjob,jobs -n <namespace>
```

For kubectl, a standalone database is a Deployment and a replicated database is a StatefulSet. The password is in the <name>-auth Secret.