Skip to main content
Qovery creates it in the AWS account of the environment’s cluster, as a Blueprint service in one of your environments.
New to this? You don’t need to know Kubernetes or Terraform. Qovery sets up Amazon ElastiCache for Valkey in your cloud account and manages it for you: you fill in a form, or paste the prompt below into your coding agent. The values it publishes, listed under Outputs, reach your other services as environment variables. Qovery tells you when a newer version of the Blueprint is available. Check the requirements in the Reference section before you start, and try it first in a development environment.

Create it

  1. Open the environment, then New service › Blueprint.
  2. Find Amazon ElastiCache for Valkey in the catalog and pick the major version.
  3. Fill in the variables. Required ones are marked; the others use their defaults.
  4. Create the service, and deploy it now or later.
You don’t add any file to your repository. Qovery creates the Blueprint from the Console or the API.

Variables and outputs

Generated from qbm.yml at AWS/valkey/9/1.0.2, the manifest the Console form is built from.
Outputs become environment variables that other services in the environment can use. By default Qovery also creates an alias for each output, prefixed with the Blueprint’s name; see Aliases Qovery creates for outputs for the naming rules and the cases where no alias is created.
Secret variables and outputs are encrypted and masked in Qovery, but Terraform can also keep their values, and values derived from them, in its state. With the Qovery-managed state backend (the default), Qovery stores the state. If you use your own backend, protect it and keep state files out of version control.

Reference

From the Blueprint’s README. Creates an AWS ElastiCache for Valkey 9 replication group with configurable node type, topology, backups, maintenance window, and network settings. Traffic is encrypted in transit and protected by an auth token, and data is encrypted at rest. The replication group id is valkey_name lowercased (AWS requirement). Applications connect over TLS as the built-in default user with the auth token as password: rediss://default:<token>@<host>:6379/0, published as the valkey_url output. The rediss:// scheme is correct here and not a leftover: Valkey speaks the Redis protocol, so Redis clients and URLs work unchanged — which is what makes it a drop-in replacement. Engine versions 9.0 and 9.1 share the valkey9 parameter group family, so either can be selected without changing the derived parameter group. AWS states that Valkey 9 parameter groups are incompatible with Valkey 8.x and Redis, which is why Valkey 9 is its own blueprint rather than a version choice inside the Valkey 8 one.

Variables

Required

Available node types: cache.t3.micro, cache.t3.small, cache.t3.medium, cache.t4g.micro, cache.r6g.large, cache.r6g.xlarge — the same set the Redis blueprint offers.

Credentials

In the Console, leaving the field blank omits it. Through the API or Terraform, omit the variable rather than sending an empty string: the platform rejects an empty variable value.

Instance & topology

instances_number = 1 creates a single node with no replica. Above 1, the group switches to cluster mode: N shards, one replica each (so 2N nodes), with automatic failover and Multi-AZ enabled because AWS requires both there, and the default.valkey9.cluster.on parameter group instead of default.valkey9. Clients then need a cluster-aware Valkey library and the valkey_configuration_endpoint_address output. Pick the topology at creation. ElastiCache cannot turn cluster mode on for an existing group, so raising instances_number from 1 fails at apply rather than resharding — deploy a new service instead. Changing it between two cluster-mode values (2 → 4) does reshard in place.

Security

Encryption in transit is always on and is not a variable: ElastiCache only accepts an auth token on a TLS-enabled group, so a group without TLS would also be a group reachable with no password by anything inside the cluster security group. Clients must connect with rediss://.

Network

By default the group is attached to the Qovery cluster network: the ElastiCache subnet group created at cluster bootstrap (named elasticache-<cluster vpc id>) and the cluster workers security group, so pods in the cluster can reach Valkey out of the box. On clusters deployed into an existing VPC (user-provided network), the ClusterId tag lookup may not resolve and the bootstrap subnet group may not exist; set both variables explicitly in that case.

Maintenance & upgrades

The window is lowercased before it reaches AWS, which is how AWS stores and reports it, so a changed window applies without leaving a diff behind.

Backups

With skip_final_snapshot = false, destroying the service leaves a snapshot named <replication group id>-final-snap-<creation timestamp> behind, which keeps costing storage until deleted. The timestamp is stamped once at creation, so it is unique per group — successive create/destroy cycles of the same name do not collide on an existing snapshot id — while staying stable across plans. snapshot_name is read at creation only: pointing it at a different snapshot later does nothing.

Outputs

Lifecycle ignore_changes

  • log_delivery_configuration, notification_topic_arn, user_group_ids — configured outside the blueprint.
  • transit_encryption_mode — AWS picks preferred vs required and reports its own value back.
  • tags — preserves tags set on the group outside the blueprint.
engine_version is deliberately not ignored, so a version change applies. ElastiCache only upgrades forward.

Auth token

auth_token and auth_token_update_strategy are deliberately not ignored. An adopted group’s state holds no token, and the AWS provider sends the token from state on any update of the group: ignored, it would reach AWS empty and the apply would fail with Invalid AUTH token provided. So the first apply after an adoption sends valkey_password with ROTATE, immediately: the provider forces ApplyImmediately on that call, whatever apply_changes_now says. Nothing here checks valkey_password against the live token. Set it to the live one: a stale value is added as a second valid token. Rehearsed on Redis 7 only (2026-11-03, a 7.0 replication group with the live token): AWS accepted the call and the token kept working. Not run on Valkey. Changing valkey_password later rotates through Terraform: ROTATE adds the new token and keeps the old one valid. Revoke the old one with aws elasticache modify-replication-group --replication-group-id <id> --auth-token <new> --auth-token-update-strategy SET --apply-immediately. Before moving a service created on an earlier version to this one, make valkey_password equal the group’s live token. Earlier versions ignored auth_token, so a token rotated out-of-band left the old one in state, and the first apply on this version sends valkey_password with ROTATE.

Required AWS IAM permissions

The credentials used to deploy this blueprint must allow the actions below. EC2 read actions are needed so Terraform can look up the cluster VPC and workers security group when the network variables are left empty.