Why Temporal Kubernetes deployment with Helm needs its versions chosen first
The Helm chart version, the server image version, and the persistence and visibility stores must be chosen together before the first install, and the chart version must match the server line. A platform team that has chosen self-hosted Temporal and wants it on Kubernetes through the official Helm charts is making several linked decisions at once. The Temporal server is MIT-licensed and runs as separate frontend, history, matching and worker services, each in its own pods, so the chart is deploying a distributed system. If the team would rather not operate that cluster, Temporal Cloud is the managed option from Temporal Technologies, and that choice should be settled before any chart is pulled.
The first constraint is compatibility. Helm chart versions below 0.73.1 do not work with server images 1.30 and later, so a chart copied from an older example can fail against a current image. Pin the chart and every server image together in version control, and confirm the pairing against the release notes and deployment documentation for the exact versions you plan to run. Do not assume the newest chart matches the newest server patch. Record which minor line each service runs, because the upgrade path later depends on that record and on the one-minor-at-a-time rule that governs server upgrades.
Persistence is the second decision. Temporal's persistence layer is tested on Cassandra 3.11, 4.0 and 5.0.4 or later, PostgreSQL 13 to 16, and MySQL 5.7 and 8.0.19 or later, while SQLite is meant only for development and testing. Advanced visibility is a separate store with its own support matrix. Elasticsearch 7 and 8 and OpenSearch 2 or later are supported from server 1.30.1, and Cassandra visibility was removed in 1.24. The documentation recommends Elasticsearch or OpenSearch for anything beyond a few workflow executions. Choose the database engine and version that your operations team can back up, patch and restore, and confirm that the visibility store is supported by the server line you selected.
Two defaults need deliberate decisions before the first deployment. If no Authorizer is configured, self-hosted Temporal uses the noopAuthorizer, which allows every API request with no authentication or access control, so the access model must be designed up front. The deployment documentation also says Temporal services should run on hosts that are not reachable from the public internet, with access limited to trusted internal networks. Decide how workers and the Web UI reach the frontend, how namespaces will be controlled, and which network policies apply before any workflow traffic flows. Confirm each of these in the Helm values with your platform and security teams so the first deployment does not also become the first security review.
Which Temporal services, stores and charts the Kubernetes deployment touches
The Kubernetes deployment touches five parts that must agree with each other: the four Temporal Server services, the Web UI, a persistence store, an advanced visibility store and the Helm charts that deploy them. A version choice in one part constrains the others, so confirm them together before you size, secure or upgrade anything.
Temporal Server services
The Temporal Server runs four services. Frontend receives API calls from clients and workers, history owns workflow state and event histories, matching routes tasks to workers through task queues, and worker runs the server's own internal system workflows. These are separate from your application workers. Confirm the replica counts and resource requests for each service, and confirm which services your chart version deploys by default before you run load tests.
Web UI
The Web UI gives operators a browser view of namespaces, workflow executions, event histories and task queues. It runs as its own deployment and reaches the frontend service. Decide how operators sign in, because OIDC single sign-on is available for the Web UI and a default configuration carries no access control. Confirm that the Web UI is reachable only from trusted internal networks and that its ingress is covered by your certificate and access policies.
Persistence store
The persistence store holds workflow state, event histories and task data. Temporal is tested on Cassandra 3.11, 4.0 and 5.0.4 or later, PostgreSQL 13 to 16, and MySQL 5.7 and 8.0.19 or later. SQLite is meant only for development and testing. Confirm the database version against your chart and server release, decide whether the database runs in the cluster or as a managed service, and plan schema setup before the first server start.
Advanced visibility store
The advanced visibility store indexes workflow executions so operators can search and filter them in the Web UI and API. Supported options are Elasticsearch 7 and 8, and OpenSearch 2 or later from Temporal Server 1.30.1. MySQL 8.0.17 or later, PostgreSQL 12 or later and SQLite are supported from 1.20. Cassandra visibility was removed in 1.24. Temporal recommends Elasticsearch or OpenSearch beyond a few workflow executions, so confirm your expected execution volume early.
Official Helm charts
The official Helm charts run the Temporal Server services in individual Kubernetes pods and set the database and visibility connection settings. Chart versions below 0.73.1 do not work with server images 1.30 and later, so the chart version and server image tag must be chosen together. Confirm the chart version, image tag and values for each environment, and keep them in version control so that upgrades and rollbacks are repeatable.
Decisions to make before the first helm install
This table compares the choices that shape a Temporal Helm deployment before any chart is installed, with the operational cost each one adds. Read each option against your data residency needs, your team's upgrade capacity and your expected visibility query load. The main takeaway is that persistence, search and version pinning decisions are costly to reverse after go-live.
| Decision | When it fits | Operational cost |
|---|---|---|
| Chart-managed persistence and visibility | Evaluation, proof of concept or a small test cluster where speed matters more than control | Least setup effort, but you still own backups, capacity planning and recovery of the database the chart deploys |
| Externally managed persistence and visibility | Production clusters that need your existing database standards, backup tooling and access controls | You provision and patch the database, confirm supported versions (PostgreSQL 13 to 16, MySQL 8.0.19 or later, Cassandra) and run schema upgrades |
| External Elasticsearch 7 or 8, or OpenSearch 2 or later | Any production use beyond a few workflow executions, where visibility queries must stay responsive | A separate search cluster to size, secure, back up and upgrade, with support as listed in the visibility docs |
| Pinned chart and server image | Regulated or change-controlled environments that test each upgrade before rollout | Your team tracks upgrade notes and tests each minor step, and upgrades one minor version at a time |
| Following the latest chart and server image | Teams with a test pipeline that can absorb frequent changes and want the newest fixes quickly | Constant review of release notes and more frequent rollouts, with higher risk of breaking changes in production |
| Workers in the same cluster as the Temporal Service | Small estates or early stages where one platform team owns both services | Shared node capacity and one upgrade window, so worker load can affect frontend and history services |
| Workers in a separate cluster | Teams that need independent scaling, separate ownership or isolation of application code from the platform | A second cluster to run, network paths to secure and workers to version alongside SDK upgrades |
| Self-hosted Temporal Service | Organizations that must keep workflow data inside their own infrastructure or control the service end to end | Your team pays for infrastructure, on-call coverage and each server and chart upgrade |
| Temporal Cloud | Teams that want Temporal to operate the service and accept its hosted SLA and pricing model | Recurring action and storage charges, with support add-ons priced separately per the Temporal pricing page |
How to build the Temporal Helm deployment step by step
This sequence takes a team from a compatible chart and server pairing to a running, tested self-hosted Temporal Service on Kubernetes. Each step closes with a check, so problems surface before the next component depends on it.
Confirm the chart and server image pairing
Start by choosing the Helm chart version and the server image line together, using the official deployment documentation and the current release notes for your target minor version. Helm chart versions below 0.73.1 do not work with server images 1.30 and later, so an older chart cannot be used with a current server line. Record the chart version, the image tag and the minor version in your deployment notes so every later step uses the same pair. The step is done when the pair appears in the release notes for the server line you intend to run, and a reviewer has signed off the recorded versions.
Provision the persistence database
Create the database that holds Temporal's workflow state, using a version inside the range the persistence documentation lists for your chosen store. The documentation lists tested ranges for Cassandra, PostgreSQL and MySQL, and SQLite is meant only for development and testing. Confirm the exact supported range against the current Temporal persistence documentation before you provision, because ranges change between server lines. Your platform or database team owns this step. It is done when the database accepts connections from the cluster network, the schema tooling can reach it, and the schema setup has completed without errors.
Provision and verify the visibility store
Provision the store that serves workflow search and listing, which is separate from the persistence store. Check the visibility documentation for the store types and versions supported by your server line, since support differs across Elasticsearch, OpenSearch, MySQL and PostgreSQL and has changed across minor releases. Cassandra visibility was removed in 1.24, and the documentation recommends Elasticsearch or OpenSearch for anything beyond a few workflow executions. The step is done when the cluster can reach the store, the index or schema setup has run, and a health check against the store returns a healthy status.
Create the namespace and set external endpoints
Create a dedicated Kubernetes namespace for the Temporal services, then store database credentials in Kubernetes secrets rather than in chart values files. Set the values file to point the persistence and visibility settings at the external endpoints you provisioned, and confirm the hostnames, ports and TLS settings with the platform team. Keep the values file in version control so it can be reviewed and reproduced. The step is done when a dry-run render of the chart produces the expected connection settings for both stores and no secret values appear in the rendered manifests or the repository.
Install the chart with pinned versions
Install the chart with the chart version and every image tag set explicitly, so the release does not pick up a newer version by accident. Run the install with the values file from the previous step and watch the release status until Helm reports it as deployed. Keep the install command in a script or pipeline definition so an upgrade or rebuild uses the same inputs. The step is done when the release shows as deployed, Helm reports no failed hooks, and the pinned chart version and image tags match the pair you recorded in the first step.
Confirm each service pod is ready
Check that each Temporal service runs in its own pod and reports ready: frontend, history, matching and worker, along with the Web UI if the chart deploys it. Use the cluster's pod status and event output to find crash loops, failed database connections or schema mismatches, and read the logs of any pod that does not become ready. Confirm that the frontend service answers requests from inside the cluster before you go on. The step is done when every expected pod is ready for a sustained period and the frontend responds to a basic health request.
Run a workflow and worker end to end
Register a test namespace with the Temporal command-line tooling, then start a worker from a small sample workflow and activity in your chosen SDK language. Start one workflow execution, let the worker complete it, and confirm the execution appears in the Web UI or through the visibility query path. Use a test namespace so the check does not touch production data. The step is done when the execution reaches the completed state, the worker logs show the activity ran, and the same execution is returned by a visibility query, which proves the persistence and visibility paths both work.
Place the Web UI and frontend behind internal networking
Restrict access to the Web UI and the frontend service to trusted internal networks, using the cluster's network policies, internal load balancers or an internal ingress. The security documentation notes that the default authorizer allows every API request with no authentication, so network isolation is the first control you apply, not the last. Plan authentication and authorization as a separate workstream before any user or application outside the trusted network connects. The step is done when a request from outside the trusted network is refused and the same request from an approved network succeeds.
How the Kubernetes setup changes for single-cluster, highly available and air-gapped installs
A single-cluster install is the simplest shape: one Kubernetes cluster, the Temporal Service pods running alongside a database that the team can reach, and an optional visibility store. It suits evaluation, development, or a small production setup where a short outage during maintenance is acceptable. The chart values can stay close to the defaults, but you still need to choose a persistence store. SQLite is only meant for development and testing, so a production-intent cluster needs PostgreSQL, MySQL or Cassandra within the supported version ranges.
What changes in this model:
- Chart values: Set the persistence backend and credentials explicitly, and pin the chart version to one that matches the server image line you plan to run.
- Store sizing: Size the database for one schema and one set of history data, with backup and restore tested on that single instance.
- Image mirroring: Images can usually be pulled from public registries, but pin image tags so an upgrade is a deliberate change.
- Network paths: Expose the frontend only to trusted internal clients, not the public internet, and keep the database reachable only from the Temporal pods.
- Visibility: Decide early whether a single Elasticsearch or OpenSearch instance is needed, because visibility queries grow with workflow volume.
Confirm with your platform team which chart and server versions are approved, which database version your organization supports, and whether a single cluster meets your recovery expectations.
A highly available install spreads the Temporal services across multiple availability zones in one region, or across clusters if your design requires it, and usually moves persistence to managed databases that handle replication and failover. The Helm release then points at external stores rather than in-cluster databases. Scaling each service (frontend, history, matching and worker) is a separate decision, and the values file needs to reflect that split rather than a single replica count.
What changes in this model:
- Chart values: Disable in-cluster database subcharts, set external endpoints and secrets references, and define replica counts and resource requests for each service.
- Store sizing: Confirm that the managed database tier supports the connection count, storage growth and failover behavior your history volume requires.
- Image mirroring: Keep the same pinned image tags across zones, and mirror them into a registry the cluster can reach if the cluster cannot pull from public sources.
- Network paths: Restrict traffic between services and the database to private subnets, and plan for internode traffic between zones.
- Visibility: Use a clustered Elasticsearch or OpenSearch deployment that can tolerate the loss of a node without losing search.
Confirm with the database provider which failover mode and recovery point objective apply to your tier, how zone failures are tested, and whether the cloud provider's managed Kubernetes supports the pod topology spread you plan to use.
An air-gapped install runs in a cluster with no route to public registries or the chart repository. Every container image, Helm chart and dependency must be copied in through an approved transfer process and served from an internal registry or chart repository. The chart values then point at internal image names, and the release process must include a mirror step for each upgrade. Because the server, schema tools and SDK-facing components can have version coupling, the mirrored set must be complete and matched.
What changes in this model:
- Chart values: Override every image repository to the internal registry, set pull secrets, and disable any default that fetches from the internet.
- Store sizing: Plan for the database and visibility store inside the enclave, with backups stored on approved media and restore tested inside the same network.
- Image mirroring: Mirror the server, admin tools and any sidecar images with their exact digests, and record the chart version used to render them.
- Network paths: Allow traffic only between the approved clusters, databases and worker networks, and document every exception for the security team.
- Upgrades: Each upgrade needs a new mirror set and a schema step, so schedule transfer time into the change window.
Confirm with the security team how artifacts cross the boundary, whether the chart repository can be hosted internally, and which Temporal server versions your mirror process has been tested against.
What drives the effort and cost of a Temporal Helm deployment
This table lists the factors that change how much work a self-hosted Temporal deployment on Kubernetes takes to build, run and keep current, with what raises effort and how to keep it under control. Read it before requesting a quote, because each row maps to a question the scope should answer. The main takeaway is that the store choices, the upgrade commitment and the compliance evidence requirements usually matter more than the chart install itself.
| Driver | What raises effort | How to keep it down |
|---|---|---|
| Number of environments | Separate dev, staging and production clusters each need their own values files, store instances, secrets and upgrade rehearsals. | Keep one chart and one values structure with per-environment overrides, and limit staging to a realistic but smaller footprint. |
| Persistence store choice and ownership | Self-managed Cassandra, PostgreSQL or MySQL means the team also operates backups, failover, patching and capacity. Supported versions differ by store and must be checked against the server release. | Use a managed database service where your organization already runs one, and confirm the store version against the Temporal persistence list before build starts. |
| Visibility store choice and ownership | Elasticsearch or OpenSearch is recommended beyond a few workflow executions, and a separate cluster adds sizing, index management and upgrade work. Cassandra visibility is no longer available. | Decide early whether SQL-based visibility is acceptable for expected volume, and confirm supported Elasticsearch, OpenSearch or SQL versions for the chosen server line. |
| Data volume and retention | High execution rates, large payloads and long retention periods grow both stores and slow visibility queries, which increases tuning and capacity planning. | Set workflow retention per namespace, keep payloads small, and agree the expected execution rate and history size in writing before sizing. |
| Namespaces and workers | Each namespace adds configuration, access rules and monitoring scope. Each worker deployment adds a separate SDK version, scaling policy and release path. | Group workloads into a small number of namespaces with clear owners, and document which worker fleets run which task queues. |
| Identity and network integration | Connecting the Web UI to an existing OIDC provider, mapping claims to namespace roles, enabling mTLS and restricting network access all require coordination with identity and network teams. Default settings allow every API request, so these steps cannot be skipped. | Agree the identity provider, claim names, certificate authority and network zones in the scope, and reuse existing platform patterns for ingress and certificates. |
| Compliance evidence requirements | Assessors may ask for documented configuration baselines, access reviews, backup and restore test records, change logs and upgrade history. Each evidence item needs a repeatable collection method. | Define the evidence list during design, automate exports from Git and cluster tooling, and confirm with your auditor which artifacts they expect. DeployOpen prepares evidence but does not issue assessments. |
| Upgrade cadence commitment | Temporal should be upgraded one minor version at a time, with schema changes applied before server upgrades when release notes call for them. A slow or irregular cadence means larger, riskier jumps and more rework of chart versions. | Commit to a fixed review cycle, keep a staging rehearsal path, and check chart compatibility with each server line before every upgrade. |
How to verify the Temporal deployment works and fails safely
Verification should prove two things: that the Temporal Service works under normal conditions, and that it fails in a visible, controlled way when a dependency breaks. Start with the basics. Confirm that every frontend, history, matching and internal worker pod reports ready and that the Helm release shows as deployed. Then confirm that a worker running outside the Temporal pods can open a connection to the frontend service, register on a task queue and poll for tasks. Record the chart version, server image tag and SDK version used for each check, because the results only mean something for that exact combination.
Next, test durability. Start a test workflow that includes a timer and several activities, then restart the worker pod while the workflow is still running. The workflow should resume on a replacement worker and complete, with its event history intact. Then run visibility queries against the test executions, filtering by workflow type and by any custom search attributes your design depends on. If the visibility store is Elasticsearch or OpenSearch, confirm the version against the visibility documentation before you trust the results. Ask the team to measure how long newly completed executions take to appear in list queries, since that delay depends on the store and load.
Now test failure behavior. In a non-production cluster, block network access from the Temporal services to the persistence database, or give them an incorrect credential, and confirm that an alert fires for the failed store connection. Also confirm that the affected services report errors to clients and that no workflow start is accepted and then silently lost. Next, check exposure. From a network outside your trusted internal ranges, including any public address space, attempt to reach the frontend gRPC port and the Web UI. Every attempt should fail. Finally, confirm that the default noopAuthorizer has been replaced with your configured Authorizer and ClaimMapper, and that an unauthenticated request is rejected before any namespace is shared with other teams.
Test rollback before you need it. In a non-production cluster, install the chart version you currently run, run the full verification set, then upgrade to the target version and run it again. Roll back with the Helm release history and repeat the checks. Confirm the chart and server image pairing against the deployment documentation, since chart versions below 0.73.1 do not work with server images 1.30 and later. Schema changes may not reverse when a chart is rolled back, so review the release notes for that version, take a tested database backup first and confirm the required schema step with your database owner. Keep the results of each run as the record for the production change.
Securing the Kubernetes install before anything connects to it
The official Helm charts start the Temporal Server with default settings, and some of those defaults favor getting a cluster running over locking it down. The cards below cover the Helm-specific controls to set before any worker, client or Web UI connects. Each one is a decision to record and verify in your own values files. The separate security hardening topic covers each control in depth.
Authorizer before first connection
If no Authorizer is configured, the Temporal Server uses the default noopAuthorizer, which allows every API request with no authentication or access control. In a Helm install, the authorizer setting belongs in the values you deploy, so a cluster that starts without it accepts calls from any pod that can reach the frontend service. Check the rendered configuration after each install and upgrade, and confirm that the no-op default is gone before any worker or client connects.
Separate mTLS for internode and frontend
Temporal configures mTLS separately for internode traffic between its services and for frontend traffic from clients and workers. Enabling one does not cover the other, so a cluster can encrypt service-to-service calls while clients still connect in plain text. Set both blocks deliberately in the Helm values, decide which certificate authority signs each, and test a worker connection and an internal service call after every change.
ClaimMapper for namespace roles
The ClaimMapper turns JWT or certificate claims into namespace roles, so the identity a caller presents determines what it may do in each namespace. Map claims from your identity provider or client certificates on purpose, and keep that mapping in version control alongside the rest of the Helm values. Confirm with a test identity that a caller without the right claim is refused in a namespace it should not reach.
OIDC sign-on for the Web UI
OIDC single sign-on can protect the Temporal Web UI, which shows workflow histories and lets operators act on executions. Decide which identity provider and client registration the UI uses, and which groups may view which namespaces. Test sign-in, sign-out and token expiry in a non-production namespace before operators depend on the UI during an incident.
Credentials in Kubernetes secrets
The persistence store and the Elasticsearch or OpenSearch visibility store both need credentials. In a Kubernetes install, those credentials belong in Kubernetes secrets, kept out of plain values files. Confirm how your chart version reads these secrets, who can read them through the Kubernetes API, and whether your cluster encrypts secrets at rest. Plan credential rotation as a documented procedure, since a rotation that restarts services needs a scheduled window.
Services on private hosts only
The Temporal deployment documentation says services should run on hosts the public internet cannot reach, with network access limited to trusted internal networks. In Kubernetes, that means no public load balancer or ingress in front of the frontend service, network policies that limit which namespaces can reach it, and the Web UI exposed only through the identity controls above. Verify from outside your network that no Temporal port answers.
What to monitor, back up, upgrade and document after go-live
The first deployment is the easy part. What keeps a Temporal Service on Kubernetes healthy is the routine work that follows: tracking server releases, upgrading on a deliberate schedule, backing up the stores that hold workflow state, watching the pods and databases, and writing down what is running. Start by deciding who owns each of these tasks. Name one owner for the Helm release, one for the persistence store, one for the visibility store, and one for the on-call response, and record those names where the platform team will find them.
Track two version lines separately. The Temporal Server has minor releases and patch releases on each minor line, and the GitHub releases page is the place to see both. Subscribe the owner to that feed. When a new patch arrives on your current minor, schedule it. When a new minor arrives, plan the move rather than jumping ahead. The upgrade rule is one minor version at a time, moving to the latest patch of the current minor first, because backward compatibility is only guaranteed between successive minor versions. Check the release notes before every move, since they state whether a schema upgrade must run before the server upgrades. The full procedure, including Helm chart changes, belongs to the upgrades topic, so treat this section as the checklist for when to start that work.
Keep the Helm chart version matched to the server image in every change. Chart versions below 0.73.1 do not work with server images 1.30 and later, so a server bump that is not paired with a compatible chart will fail in a way that looks like a cluster problem. Store the chart version and the image tag together in version control so a rollback restores both. Confirm the exact chart version for your target server release with the official chart repository before you merge.
Backups need two targets. The persistence store holds workflow execution history, and the visibility store holds the searchable index of executions. Back up the persistence database with the backup tooling your database platform provides, and test restores into a separate environment on a schedule. Treat the visibility index differently: if it can be rebuilt from persistence, document the rebuild steps and how long your team expects them to take, and confirm the approach with your database and search platform owners before relying on it. Ask whether the backup schedule meets your recovery expectations for running workflows, because a restore gives you the state at a point in time.
Monitor at three layers. For the Temporal services, watch the frontend, history, matching and worker pods for restarts, resource pressure and error rates. For the stores, watch database connections, replication lag or storage growth on the persistence database, and indexing health on Elasticsearch or OpenSearch. For the workflows themselves, alert on task queue backlog and workflow failure rates. Finally, write a runbook that records the Helm values file location, the current chart version and server image tag, the namespaces for each component, the database endpoints, and the owner for each item. Review and update the runbook at every upgrade so it always describes the cluster as it runs today.
Questions teams ask before deploying Temporal on Kubernetes with Helm
How much does a Temporal Helm deployment on Kubernetes cost?
The cost has two parts: one-time work to plan and build the deployment, and recurring cost to run it. Recurring items include Kubernetes capacity for the frontend, history, matching and worker services, the persistence database (Cassandra, PostgreSQL or MySQL), an Elasticsearch or OpenSearch cluster for advanced visibility, backups, monitoring, and staff time for upgrades and on-call. The Temporal server is MIT licensed, so there is no server license fee, but infrastructure and people are paid for. Cost rises with workflow volume, retention period, the number of namespaces and the number of environments. DeployOpen does not publish a price list. A quote follows from a written scope, so ask for each component, who pays for it, and which items recur.
How long does it take to deploy Temporal on Kubernetes with Helm?
The timeline depends on the written scope, so ask for it as part of the agreement. Most DeployOpen engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts. The main drivers are the number of environments, whether the persistence and visibility stores already exist or must be built, how many network and identity integrations are needed, whether mTLS and authorization are included, and how many change windows your organization requires. Existing Kubernetes platform pieces, managed databases and an identity provider shorten the work. Missing pieces add steps that should be listed in the plan before anyone commits to a date.
Can our own platform team deploy Temporal on Kubernetes without a partner?
A team with solid Kubernetes, database and identity experience can install the official Helm charts, but the risk sits in the details. Chart and server versions must match, since Helm chart versions below 0.73.1 do not work with server images 1.30 and later. Schema changes must run before server upgrades when release notes call for them. Without a configured Authorizer, self-hosted Temporal allows every API request, so access control has to be planned from day one. Ask whether you have an owner who will handle upgrades one minor version at a time for the life of the service. DeployOpen can plan, implement, harden, document and support the deployment inside your own infrastructure, or hand the runbooks to your team.
What do we need to provide for a Temporal Helm deployment?
Expect to provide access and decisions in five areas. Cluster access: a target namespace, permission to install charts, node capacity, and an ingress or load balancer path. Store access: credentials, network routes and rights to create databases or keyspaces for persistence and visibility, plus a backup plan. Identity details: the OIDC issuer, client registration for the Web UI, and which token claims map to namespace roles. Certificates and DNS: the PKI for mTLS and the names for the frontend. Change windows: dates for staging and production, and named approvers. Temporal services should run on hosts not reachable from the public internet, so network rules must also be agreed. Confirm the exact list during scoping.
Which Temporal chart and server versions should we pin, and where do we confirm them?
Pin a chart version and a server image version together, and confirm both before any install. Temporal Server v1.32.1 was published on GitHub on October 8, 2026, with patch releases v1.31.4 and v1.30.8 published on October 12, 2026 for earlier minor lines. Helm chart versions below 0.73.1 do not work with server images 1.30 and later. Confirm the compatible chart for your target server in the Temporal self-hosted deployment documentation and the GitHub releases page. Upgrade one minor version at a time, moving to the latest patch of your current minor first, and record both pins in version control so every environment matches.
Is Temporal Cloud a better fit than self-hosting for a small team?
The answer depends on who will run the databases, Elasticsearch, upgrades and on-call, and on what your data rules allow. Temporal Cloud pricing is usage-based: pay-as-you-go starts at 50 US dollars per million actions, with active storage at 0.042 dollars per GB-hour and retained storage at 0.00105 dollars per GB-hour, according to Temporal's pricing page. Temporal Cloud lists a 99.9% SLA, or 99.99% with high availability, and SAML SSO. Support add-ons start with Business at 500 US dollars per month, per the same page. Self-hosting avoids a server license fee under the MIT license but moves infrastructure and staff costs to your team. Model both options with your expected action volume, storage and staff time.
Do we need single sign-on and authorization before going live?
Yes. If no Authorizer is configured, self-hosted Temporal uses the default noopAuthorizer, which allows every API request with no authentication or access control. Plan the ClaimMapper, the Authorizer and OIDC single sign-on for the Web UI as part of the first deployment, not as a later step. Self-hosted Temporal also supports mTLS with separate settings for internode and frontend traffic, so decide how certificates are issued and rotated early. Ask your identity team for the issuer, the client registration details and the claims that map to namespace roles. Keep the services on hosts not reachable from the public internet, with access limited to trusted internal networks.
How DeployOpen scopes, builds and hands over a Temporal Helm deployment
DeployOpen plans, implements and documents self-hosted Temporal inside your own cloud accounts, data centers or air-gapped networks. For a Helm deployment, we start from the chart and server versions you need, the external persistence and visibility stores, and how workers will run alongside the service. Each step is written down so your team can operate it after go-live.
How we scope
- The written scope names the Temporal server version, Helm chart version and Kubernetes cluster the deployment targets.
- It lists the persistence store, the advanced visibility store and which Temporal services run as separate pods.
- Engagements are fixed-scope, agreed in writing before work starts, with ongoing support available as a retainer.
How we build
- Chart and server versions are matched first, since charts below 0.73.1 do not work with server 1.30 and later.
- External databases and Elasticsearch or OpenSearch are configured and connected, with secrets kept out of values files.
- Worker deployments run alongside the service with their own scaling settings, tested against the same namespaces.
How we hand over
- Handover includes the values files, pinned chart versions and a runbook for upgrades, scaling and rollback.
- Test evidence covers install, service health, namespace creation, a sample workflow run and a pod restart.
- Architecture notes flag security gaps, including the default Authorizer that allows every API request until one is configured.
How we support
- Retainers can cover Temporal server upgrades one minor version at a time, with schema changes run first.
- Support can include Helm chart compatibility checks and worker SDK upgrades when your release plan calls for them.
- Changes after go-live are agreed in writing, so the original scope stays a reference point.
