TechPrufer
Get started
Temporal
Temporal logoTemporal · Feature trail

Temporal Server Deployment Automation

2 posts · Jan 2022 – Apr 2026

What this trail covers

Temporal Cloud offers a managed, scalable, and cost-effective solution for running Temporal clusters, abstracting away the complexities of self-hosting. For self-hosted deployments, Temporal provides guidance on scaling through metrics, configuration tuning (e.g., shard count, resource allocation), and leveraging Kubernetes for deployment and management. The focus is on a load-measure-scale iteration loop to optimize performance and reliability. This post details the auto-setup script which simplifies deployment and the 1.0.0 release of the Helm Charts, which now require users to provide their own database and optional components like Elasticsearch, Prometheus, and Grafana, while adding configurable readiness probes, custom deployment strategies, and improved log level control.

All Temporal trails
  1. An important milestone for Temporal’s Helm ChartsThe Helm Charts for deploying the Temporal Service to Kubernetes have reached version 1.0.0. This release signifies stability and introduces several breaking changes, including the removal of bundled sub-charts for databases (Cassandra, PostgreSQL, MySQL) and optional components (Elasticware, Prometheus, Grafana), requiring users to provide and configure these externally. The `values.yaml` structure has been updated, and specific keys like `server.internalFrontend` and `imagePullSecrets` have changed format. New capabilities include configurable readiness probes, custom deployment strategies, `minReadySeconds` for rollout control, configurable log levels, and support for AWS IAM authentication and TLS for Elasticsearch/OpenSearch. The post also highlights community contributions and provides guidance on upgrading and getting started.
  2. Scaling Temporal: The basicsThis post details a practical approach to scaling a self-hosted Temporal cluster deployed on Kubernetes with a MySQL backend. It introduces a load-measure-scale iteration loop, emphasizing the use of 'State Transitions' as a key performance metric. The post highlights the critical role of the persistence backend (MySQL) as a potential bottleneck and discusses the impact of Temporal's History Shard count on shard lock latency. It demonstrates how increasing the shard count from the development default (4) to a recommended production value (512) significantly reduces shard lock latency, but also necessitates careful monitoring and adjustment of History pod memory resources to prevent OOMKills and ensure stable operation. The post also touches upon Kubernetes resource management and the importance of setting appropriate CPU and memory requests for Temporal pods.
  3. How Temporal Auto-Setup simplifies deploymentThis post details the `auto-setup.sh` script used in Temporal deployments, explaining its role in schema setup (database and Elasticsearch), and Temporal Server setup (namespace registration and search attributes). It clarifies the distinction between setup and execution, and provides examples of how to run Temporal Server services independently or via Docker for production deployments. It also introduces the concept of `temporal-sql-tool` and `temporal-cassandra-tool` for schema management and updates.