> ## 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. # Customer-Provided Services > Customer-supplied services (managed or self-hosted) in place of default-shipped ones Three customer-provided services the customer can substitute into the deployed install — Temporal, PostgreSQL, and MongoDB — each available as managed or self-hosted. Arrows fan from the origin stack to each service card. Three customer-provided services the customer can substitute into the deployed install — Temporal, PostgreSQL, and MongoDB — each available as managed or self-hosted. Arrows fan from the origin stack to each service card. Some of your customers already operate the services (managed or self-hosted) that your application depends on, and want your application to use those instances instead of the default equivalent. Tensor9 lets your customer plug their own service into the install, and the compiler emits a deployment stack that wires to it. ## How this is different from service equivalents [Service equivalents](/fundamentals/service-equivalents) covers the **automatic** substitution: when the compiler maps RDS to Cloud SQL because the appliance is on GCP. The mapping happens automatically based on the appliance's [form factor](/fundamentals/key-concepts#form-factor); your customer does not pick. Customer-provided services is the **customer-driven** substitution: your customer explicitly says "use my Temporal" and the compiler honors that. The substitution is a customer-supplied configuration knob, not a form-factor default. The two mechanisms compose. A customer on GCP can use the default-shipped Cloud SQL (service equivalent) while bringing their own Temporal (customer-provided service). ## Services customers can provide today | Service | Compliance lever | Page | | -------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------- | | **Temporal** workflow orchestration | Data residency for workflow history; the customer's existing Temporal (Temporal Cloud or self-hosted) already lives inside their certified perimeter and their incident-response runbook. | [Temporal](/customizations/customer-provided-services/temporal) | | **PostgreSQL** relational database | Regulated data stays on the customer's already-certified database (RDS in their VPC, on-prem PostgreSQL behind their CA, etc.). Backup, patch cadence, and DBA ownership are the customer's. | [PostgreSQL](/customizations/customer-provided-services/postgresql) | | **MongoDB** document database | Document data stays in the customer's existing MongoDB (Atlas or self-hosted), under their existing access controls, network access, and backup configuration. PrivateLink to Atlas is the recommended production posture when the customer is on Atlas. | [MongoDB](/customizations/customer-provided-services/mongodb) | | **Elasticsearch** family (Elasticsearch, Lucenia, OpenSearch) | Search and log-aggregation indices stay on the customer's existing cluster, under their existing access controls, snapshot policy, and observability. Lucenia is the recommended commercial alternative (Tensor9 partner). | [Elasticsearch](/customizations/customer-provided-services/elasticsearch) | | **Kafka** event streaming | Event streams stay on the customer's existing brokers (Confluent Cloud, MSK, Strimzi, Redpanda), so retention policy, ACL administration, and cross-region replication remain the customer's responsibility. | [Kafka](/customizations/customer-provided-services/kafka) | | **Redis** cache, session store, pub/sub | Cache, session, and rate-limit state stay on the customer's existing Redis (ElastiCache, MemoryDB, Memorystore, self-hosted), under their existing eviction policy, snapshot schedule, and observability. | [Redis](/customizations/customer-provided-services/redis) | | **Valkey** cache (Linux Foundation BSD-licensed fork of Redis) | Customers who want the Redis API on a vendor-neutral OSS license. AWS ElastiCache for Valkey, GCP Memorystore for Valkey, and self-hosted Valkey are all first-class. Separate from Redis Inc. licensing. | [Valkey](/customizations/customer-provided-services/valkey) | For each supported service, the customer can plug in either a managed equivalent (Temporal Cloud, Aurora, Atlas) or their self-hosted instance — the compiler emits the right deployment stack either way. The currently-supported set is what's listed here. The set is actively expanding as customer requirements drive new substitutions; if you have a customer who needs to bring their own service that is not on this list, [contact us](mailto:hello@tensor9.com). ## What your customer configures For each supported service, your customer supplies: * A connection endpoint or address. * The credentials the appliance needs to authenticate to the service. * Any service-specific configuration (namespace, database name, bucket name, and so on). Tensor9 stores this configuration as part of the appliance's setup and the compiler reads it to emit the right deployment stack.