Valkey vs Redis
Valkey is API- and wire-compatible with Redis 7.2 and continues to evolve as a true OSS project. The two are separate products with separate governance, separate roadmaps, and separate licenses going forward:- Valkey (this page): BSD-licensed, Linux Foundation governance. Use this page when your origin stack is built on Valkey or when your customer wants the Redis API without any Redis Inc. license entanglement. AWS ElastiCache, GCP Memorystore, Aiven, and others ship Valkey as a first-class managed offering.
- Redis: the Redis Inc. product (Redis 7.4+ under SSPL / RSAL, or Redis Enterprise commercial). Use that page when your origin stack is built on Redis specifically and your customer has a Redis Inc. license or runs on a Redis-branded managed service.
What the customer provides
| Field | Purpose |
|---|---|
| Hostname | The host (or host:port if non-default) of the Valkey endpoint. For clustered Valkey, the cluster configuration endpoint. |
| Password (or IAM auth token reference) | The credential for AUTH. ElastiCache for Valkey supports IAM-backed tokens; static passwords are supported everywhere. |
| Database number (optional) | The Valkey logical database (0-15). Defaults to 0. Ignored on clustered mode. |
| TLS settings (optional) | A custom CA certificate when the customer uses a private CA. Public-CA Valkey (ElastiCache with TLS-in-transit, Memorystore) does not need this. |
| Cluster mode (optional) | Flag indicating whether the endpoint is cluster-mode vs. standalone. |
What changes in the deployment stack
When customer-provided Valkey is selected, the compiler:- Drops the default-shipped Valkey instance from the deployment stack (no ElastiCache for Valkey resource, no in-cluster Valkey StatefulSet, no automated snapshots).
- Wires the appliance’s services to the customer’s hostname.
- Injects the customer’s credentials as secrets the services read at startup.
- Sets the database number and TLS configuration the services connect with.
What the customer takes on
When your customer brings their own Valkey, they own:- Provisioning, instance sizing, and capacity planning (memory headroom + connection limits).
- Backup, snapshot, and restore. ElastiCache for Valkey and Memorystore have built-in snapshot schedules; self-hosted Valkey is the customer’s responsibility.
- Patching and version upgrades. The customer’s Valkey major version must remain compatible with your application’s client library (most Redis-protocol clients work unchanged against Valkey).
- High availability, failover, and read-replica topology.
- Eviction policy configuration (
allkeys-lru,volatile-ttl,noeviction, etc.) appropriate for your application’s use of Valkey. - Monitoring, alerting, and incident response for the Valkey instance itself.
What stays your responsibility
- All application-level concerns: key naming, TTLs, data model, command correctness.
- Your services continue to be observable through Tensor9’s normal mechanisms.
- Operations commands that operate on the appliance’s services still work normally. Operations commands cannot reach into your customer’s Valkey.
Deployment notes
AWS ElastiCache for Valkey has been available since late 2024 and is the path of least friction for customers on AWS — same managed-service ergonomics as ElastiCache for Redis, with the OSS license guarantee. ElastiCache Serverless for Valkey is also available. GCP Memorystore for Valkey is the GCP-native managed offering, available in both standard and cluster modes. Other providers (Aiven, Upstash, DigitalOcean) also offer managed Valkey; check the provider’s docs for current feature coverage. Self-hosted Valkey runs anywhere Redis runs: Kubernetes via Helm charts (the Bitnami Valkey chart is widely used), VMs, or bare metal.Authentication and rotation
The AUTH password (or IAM auth token reference) is stored as a Customer-Supplied Secret - Tensor9 has no visibility into the underlying value. The appliance reads it at startup and on every reconnection. Two rotation paths:- Static password / ACL user password: rotate in the cluster’s auth config (ElastiCache for Valkey, Memorystore for Valkey, or self-hosted admin) and update the secret in the customer’s secret store; restart the affected services so they reconnect.
- IAM auth tokens (ElastiCache for Valkey): the appliance assumes a customer-supplied IAM role and the underlying token refreshes automatically on the AWS-default 15-minute TTL. The customer rotates the role / policy, not the credential.