Managed Valkey on Zenifra

Managed Valkey provides an instance compatible with the Redis protocol for three different needs: key-value data, cache, and work queues. The card selected in the Console defines the profile; there is no later profile selector.

Required permissions

Creating any Valkey profile requires managed_service.create on organization:*. To read status, use managed_service.status.read on the project ID; for the connection, managed_service.connection.read; for rotation, managed_service.credentials.rotate. owner has full access; assistant, member, and organization API Keys need the specific grants.

Choose the right product

Product	Use it for	Durable storage	High availability	Commercial plans
Key‑Value	sessions, shared state, counters, and locks	Fixed at 1 GB on `db-free`; on other plans, capacity is chosen at creation and billed separately	One primary and two replicas on `db-basic`, `db-premium`, and `db-enterprise`; single instance on `db-free` and `db-starter`	`db-free`, `db-starter`, `db-basic`, `db-premium`, `db-enterprise`
Cache	computed responses, queries, and disposable data	None on any plan: data lives only in memory	No; single instance on every plan	`cache-free`, `cache-starter`, `cache-basic`, `cache-premium`, `cache-enterprise`
Queues	asynchronous tasks, workers, and durable events	Fixed at 1 GB on `queue-free`; 5 GB included on other plans, expandable with the excess billed	One primary and two replicas on `queue-basic`, `queue-premium`, and `queue-enterprise`; single instance on `queue-free` and `queue-starter`	`queue-free`, `queue-starter`, `queue-basic`, `queue-premium`, `queue-enterprise`

Prices, benefits, capacity, and billing mode should be read from the public catalog (GET /v1/managed-services/catalog or zenifra plans --type valkey) or the Console cards. They may change without requiring application code changes. The Premium and Enterprise plans of each profile include instance metrics on the project page, as point-in-time readings without history.

On the free Key‑Value and Queues plans, storage is fixed at 1 GB and cannot be changed during creation. Free Cache does not present a durable-storage control.

Security and connection

The endpoint is publicly reachable over IPv4, but TLS and authentication are required. The initial connection uses the valkeys:// scheme and the default username; the full password is revealed only during project creation or credential rotation.

export VALKEY_URL='valkeys://default:RECEIVED_PASSWORD@PROJECT_HOST:PROJECT_PORT/0'

Store VALKEY_URL in a secret manager or protected variable. Never put it in source code, logs, tickets, or images. Some clients do not recognize valkeys://; in that case, read the host, port, username, and password and configure TLS explicitly, or replace only the scheme with rediss://. Never disable certificate or hostname validation.

Credential rotation is asynchronous: the request is accepted with 202 and returns an operation; the new connection, including the password, appears when you read the completed operation (in the CLI, use zenifra valkey credentials rotate --wait). See Connect to Valkey for examples in eight languages and Rotate credentials for the API operation.

Choosing a profile

Choose Key‑Value when data is part of application state and must survive restarts.
Choose Cache when the application can rebuild the value and accepts expiration or eviction.
Choose Queues when work must be delivered to workers. For new integrations, start with Streams and consumer groups; use Pub/Sub only for real-time events that may be lost during a disconnect.

Create and operate

Open Create project in the Console.
Select the Valkey card for Key‑Value, Cache, or Queues.
Select a plan and billing mode. On Free Key‑Value or Queues, storage remains fixed at 1 GB; on other durable plans, choose capacity when the Console offers that option.
Wait for the service to become ready and copy the connection shown once.
Use the project page, CLI, or API to inspect status, read the masked connection, and rotate credentials.

To list only one profile through the API, call GET /v1/project with type=valkey and profile=key_value, profile=cache, or profile=queue. See the projects reference for pagination, search, status, and sorting.

Do not provide an image, runtime, port, instance count, or IP rules: these fields are not part of the public managed Valkey configuration.

Choose by data lifecycle

Before creating an instance, decide whether the value can be rebuilt, must survive restarts, and has a responsible consumer that confirms each piece of work. This avoids using Cache for important data or turning a queue into a notification channel without retention. The catalog shows the current capacity and plan benefits; the project page shows status and connection details without revealing the previous password.

Reuse one connection or pool per process and close it during application shutdown. For workers, define time limits, retries with backoff, and a strategy for messages that remain pending. For Cache, record hits, misses, latency, and rebuild rate. For Key‑Value, monitor value sizes and key count. These metrics help choose the next plan without coupling the application to infrastructure details.