Temporal Helm Chart: Designing Isolated Workflow Clusters

Direct answer

Temporal provides official Helm charts that simplify deploying Temporal Server components—Frontend, History, Matching, and Worker—to Kubernetes. The charts reached version 1.0.0 in 2026, marking a milestone of stability. A release-per-tenant model gives each customer its own Temporal cluster with isolated persistence, visibility, and operational boundaries. OpenTenant automates the tenant lifecycle around the upstream chart while Temporal remains responsible for workflow orchestration.

What the Temporal Helm chart provides

The Helm chart installs Temporal-specific components: Temporal Server, Temporal Web UI, and admin tools. As of version 1.0.0, the chart no longer includes sub-charts for bundled databases (Cassandra, PostgreSQL, MySQL) or optional components like Elasticsearch, Prometheus, and Grafana. You must provide these dependencies externally and specify connection details in configuration.

Key capabilities introduced in 1.0.0 include:

Configurable readiness probes for precise control over pod readiness
Custom deployment strategies with rolling update parameters at global and per-service levels
Configurable log levels through server.config.logLevel

The chart supports multiple deployment patterns, from minimal development setups to highly available production environments with external database dependencies.

The use case: dedicated workflow orchestration per customer

A release-per-customer model is valuable when each tenant needs:

Independent workflow history and visibility stores
Customer-specific persistence and Elasticsearch backends
Separate rate limits and namespace capacity
Controlled upgrade windows and maintenance schedules
Clean export, suspension, and deletion boundaries

Temporal documentation notes that while many SaaS providers use a single Temporal Namespace with per-tenant Task Queues, a separate Namespace per tenant is appropriate for a small number of high-value tenants requiring true isolation boundaries. A dedicated Kubernetes release adds another layer: independent runtime, database ownership, credentials, domain, network policy, and failure blast radius.

Reference architecture

tenant workflow profile
  → validate persistence and visibility requirements
  → resolve tenant-scoped database and Elasticsearch secrets
  → render Temporal values for one release
  → install into the tenant namespace
  → verify persistence, visibility, and route readiness
  → promote or roll back independently

OpenTenant references the upstream chart and compiles only per-tenant differences. The tenant declaration supplies customer-specific configuration and references to scoped secrets. Database and Elasticsearch dependencies remain part of the operational boundary—decide whether each customer receives dedicated services, dedicated databases on shared services, or a governed shared topology.

Illustrative tenant declaration

tenant: acme
userspace:
  namespace: tenant-acme-workflows
  domain: workflows.acme.example
deployment:
  engine: helm
  template: temporal
  release: temporal-acme
  config:
    persistence:
      datastores:
        cassandra:
          hosts: ["cassandra.acme.svc"]
          keyspace: temporal
    visibility:
      elasticsearch:
        url: https://elastic.acme.svc:9200
        index: temporal-visibility
  secretScope: tenants/acme/temporal

This is an architectural example. Production declarations should reference versioned templates and Secret objects rather than embedding credentials directly.

Production decisions before onboarding

Persistence topology. Temporal 1.0.0 requires an external database. Choose Cassandra, PostgreSQL, or MySQL. Decide whether isolation means separate database instances, separate keyspaces or databases, or a governed shared service.

Visibility store. Elasticsearch provides advanced visibility features. Each tenant may need a separate index or cluster depending on data isolation requirements.

Namespace strategy. Temporal Namespaces can be created per tenant within a shared cluster or per Kubernetes release. OpenTenant can coordinate namespace creation as part of the tenant lifecycle.

Schema upgrades. Temporal upgrades may involve database schema changes. Test the target version against the deployment template, back up the tenant database, and promote through controlled cohorts. A Kubernetes rollback cannot reverse an incompatible database migration.

Worker placement. Temporal workers connect to the cluster. Workers must be configured with the correct tenant namespace and task queue. Worker pools may need to be deployed per customer.

Evaluation checklist

Does every tenant have an explicit persistence and visibility store?
Are database and Elasticsearch credentials isolated and rotatable per tenant?
Can one tenant's workflow load affect another tenant's cluster?
Are Temporal Namespaces created and managed as part of the tenant lifecycle?
Can you upgrade one tenant, verify it, and stop the rollout?
Does offboarding remove routes and runtime access before deleting retained workflow history?
Are schema migrations tested and reversible?

Sources

OpenTenant's contribution is the repeatability: the persistence, visibility, route, access policy, release, and secret scope move together as one tenant lifecycle instead of separate operational tickets.