If your origin stack uses Temporal as its workflow engine, your customer can supply their own Temporal cluster (self-hosted or Temporal Cloud) and the compiler will emit a deployment stack that talks to it instead of provisioning a default-shipped Temporal.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.
What the customer provides
| Field | Purpose |
|---|---|
| Frontend address | The host:port (or URL) of the customer’s Temporal frontend service. |
| Namespace | The Temporal namespace the appliance’s workers should connect to. |
| mTLS client certificate + key | The client identity the workers present when connecting. Required for Temporal Cloud and most customer-managed Temporal deployments. |
| CA certificate | The trust anchor for the Temporal frontend’s server certificate. |
What changes at compile time
When customer-provided Temporal is selected, the compiler:- Drops the default-shipped Temporal cluster from the deployment stack (no server, no database, no UI).
- Wires the appliance’s worker pods to the customer’s frontend address.
- Injects the customer’s mTLS material as secrets the workers read at startup.
- Sets the namespace the workers register against.
What the customer takes on
When your customer brings their own Temporal, they own:- Provisioning, sizing, and scaling of the Temporal cluster (or the Temporal Cloud namespace tier).
- Worker host-pool capacity and any persistence backend (Cassandra, PostgreSQL, etc.) the Temporal cluster needs.
- Patching and version upgrades. The customer’s Temporal version must remain compatible with your Temporal SDK version; mismatches manifest as runtime errors.
- Backup, point-in-time recovery, and disaster recovery for the workflow history.
- High availability, failover, and cross-region replication.
- Operational monitoring, alerting, and incident response for the Temporal cluster itself.
What stays your responsibility
- Your worker code, workflows, and activities are unchanged.
- You remain responsible for SDK compatibility, retry policies, workflow correctness, and any application-level operational concerns the workers raise.
- Operations commands that operate on the worker pods (logs, metrics, restart) still work normally. Operations commands cannot reach into your customer’s Temporal cluster.