What the customer provides
| Field | Purpose |
|---|---|
| Hostname | The host (or host:port if non-default) of the Redis endpoint. For clustered Redis, the cluster configuration endpoint. |
| Password (or IAM auth token reference) | The credential for AUTH. ElastiCache and MemoryDB support IAM-backed tokens; static passwords are supported everywhere. |
| Database number (optional) | The Redis logical database (0-15). Defaults to 0. Ignored on clustered Redis. |
| TLS settings (optional) | A custom CA certificate when the customer uses a private CA. Public-CA Redis (ElastiCache with TLS-in-transit, MemoryDB, Memorystore) does not need this. |
| Cluster mode (optional) | Flag indicating whether the endpoint is cluster-mode (the application opens a cluster client) vs. standalone. |
What changes in the deployment stack
When customer-provided Redis is selected, the compiler:- Drops the default-shipped Redis instance from the deployment stack (no ElastiCache resource, no in-cluster Redis StatefulSet, no automated backups).
- 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 Redis, they own:- Provisioning, instance sizing, and capacity planning (memory headroom + connection limits).
- Backup, snapshot, and restore. ElastiCache and Memorystore have built-in snapshot schedules; self-hosted Redis is the customer’s responsibility.
- Patching and version upgrades. The customer’s Redis major version must remain compatible with your application’s client library.
- High availability, failover, and read-replica topology.
- Eviction policy configuration (
allkeys-lru,volatile-ttl,noeviction, etc.) appropriate for your application’s use of Redis. - Monitoring, alerting, and incident response for the Redis 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 Redis.
Deployment notes
AWS ElastiCache for Redis and MemoryDB are the most common managed paths for customers on AWS. ElastiCache supports both cluster-mode and standalone topologies; MemoryDB is durable (multi-AZ writes to a transaction log). Other cloud managed Redis (GCP Memorystore, Azure Cache for Redis) is supported the same way - hostname + password + TLS settings. Redis Enterprise is the commercial Redis Inc. product, available as Redis Cloud (managed by Redis Inc.) or Redis Software (self-hosted by the customer with a commercial license). Active-active geo-replication and Redis on Flash are Redis Enterprise features. Self-hosted Redis (Redis OSS) is the customer running Redis themselves on Kubernetes or VMs. For the BSD-licensed Linux Foundation fork, see the separate Valkey page.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 the password in the cluster’s auth config (ElastiCache, MemoryDB, or Redis Enterprise admin UI) and update the secret in the customer’s secret store; restart the affected services so they reconnect.
- IAM auth tokens (ElastiCache, MemoryDB): 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.