Skip to main content
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 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; 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

ServiceCompliance leverPage
Temporal workflow orchestrationData 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
PostgreSQL relational databaseRegulated 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
MongoDB document databaseDocument 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
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
Kafka event streamingEvent 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
Redis cache, session store, pub/subCache, 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
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
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.

​
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 at compile time to emit the right deployment stack.