> ## Documentation Index
> Fetch the complete documentation index at: https://docs.tensor9.com/llms.txt
> Use this file to discover all available pages before exploring further.
# Redis
> Customer-provided Redis deployment in place of default-shipped Redis
If your origin stack uses Redis as a cache, session store, or pub/sub bus, your customer can supply their own Redis instance and the compiler will emit a deployment stack that talks to it instead of provisioning a default-shipped Redis.
This page covers the **Redis Inc.** product family (Redis 7.4+ under SSPL / RSAL, plus Redis Enterprise / Redis Cloud). For the BSD-licensed Linux Foundation fork, see [Valkey](/customizations/customer-provided-services/valkey).
## 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.
Your application code does not change. The connection address changes; the commands the application emits do not.
## 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](/fundamentals/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](https://redis.io/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](/customizations/customer-provided-services/valkey) page.
## Authentication and rotation
The AUTH password (or IAM auth token reference) is stored as a [Customer-Supplied Secret](/fundamentals/secrets#secret-ownership-models) - 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.
## Where this fits
This page is one of the services covered by [Customer-Provided Services](/customizations/customer-provided-services). For automatic cross-cloud substitution (ElastiCache to Memorystore based on form factor), see [Service equivalents](/fundamentals/service-equivalents). See also [Valkey](/customizations/customer-provided-services/valkey) for the OSS fork.