What a Temporal implementation plan covers
A Temporal plan settles the decisions that drive cost and risk before any build starts. The first is which processes to move. Good candidates are long-running business processes that today depend on cron jobs chaining scripts, queues used as makeshift state stores, or homegrown state machines that lose their position after a restart. Ask the team to list each candidate, how long it runs, what it calls, and what happens when it fails halfway. Those answers decide the first workflows, the activities they need, and how much testing each one requires.
The plan also covers the application architecture. It names the SDK language for workflow and activity code, the task queues that separate workflow work from activity work, and the worker pools that will run them, including where those workers are deployed. It sets namespace boundaries and decides whether to run the Temporal Service yourself or use Temporal Cloud. For self-hosting, the plan must cover network placement, authentication and where the service runs. For Temporal Cloud, it must cover identity integration, data residency questions and how workers reach the cloud endpoint from your network.
Persistence and visibility stores are the next decisions. Temporal's persistence documentation lists Cassandra, PostgreSQL and MySQL as supported primary stores and says SQLite is meant only for development and testing. Confirm the exact versions in the current documentation before you commit. Visibility, which powers search over workflow executions, can use Elasticsearch or OpenSearch, and Temporal recommends one of these beyond a few workflow executions. Each store is another system to size, back up, patch and monitor, so the plan should name its owner from the start.
Partner scoping makes sense when your team has no production Temporal experience, must support several SDKs or workflow types at once, or works under audit and security requirements that the design has to satisfy from day one. Your own staff can often scope the work when they already run distributed systems, can operate the chosen data stores, and are moving one low-risk process first. Compare your team's skills against the readiness and phases sections of this page, and record the gaps, because those gaps set the scope a quote needs to cover.
What the implementation includes
A typical Temporal project moves through the work packages below. The exact list, deliverables and acceptance checks are set in the written scope before work starts, so treat each card as a component to confirm, not a fixed commitment.
Discovery and workflow inventory
We catalog the processes you want to move, such as cron-driven jobs, queue consumers and homegrown state machines, and record their steps, retries, timeouts, human waits and failure modes. The deliverable is a workflow inventory with a recommended first set of workflows. Check that the inventory names the systems each workflow calls and who owns them.
Architecture and hosting decision
This package decides between a self-hosted Temporal Service and Temporal Cloud, and records the reasons. The deliverable is an architecture decision record covering hosting, regions, network placement and operating ownership. Confirm that the record states who runs upgrades, on-call and backups under each option.
SDK and worker design
We choose the Temporal SDK language for each team, define worker processes, task queues and their scaling, and set how workers reach the service. The deliverable is worker design documentation and deployment definitions for your platform. Check how worker versions will be rolled out alongside workflow code changes.
Persistence and visibility design
We select the persistence store for workflow state and the visibility store for search, then size and configure both. Supported persistence options include Cassandra, PostgreSQL and MySQL, and Elasticsearch or OpenSearch is recommended for visibility beyond a few executions. The deliverable is a data store design with sizing assumptions and backup scope. Confirm versions against the current Temporal documentation.
Observability and security setup
We wire metrics, logs and traces for the service and workers, and configure access controls such as mTLS, an Authorizer and SSO for the Web UI when self-hosting. The deliverable includes dashboards, alert definitions and the access configuration as code. Check that the default open configuration is replaced before any production traffic arrives.
Proof of concept and production build
A proof of concept runs the first workflows end to end in a non-production environment, with failure injection and replay testing. The production build then deploys the approved design with environments, pipelines and data stores. Deliverables include test evidence, deployment definitions and a runbook. Confirm the acceptance criteria in the written scope before the build begins.
Handover and operations runbook
The handover transfers the running platform to your team with documented procedures for upgrades, scaling, incident response and workflow versioning. The deliverable is a runbook and a training session agreed in scope. Check whether ongoing support, upgrades or testing are included, or whether they need a separate retainer.
What drives cost and duration
Each row names one factor that moves Temporal project effort or running cost, why it matters, and how to keep it under control.
| Driver | Why it moves effort or cost | How to keep it down |
|---|---|---|
| Number and complexity of workflows | Each workflow needs design, retry and timeout decisions, signal and query handling, and tests. Long-running branching logic takes the most design and review time. | Start with the first two or three processes that have the clearest business value. Keep workflows small, and push external calls into activities. |
| Activities calling external systems | Every external call needs idempotency keys, retry policies and failure handling. Each new system adds integration work and test doubles. | Inventory the systems each workflow touches before scoping. Reuse one shared client library for common systems such as payments or email. |
| SDK languages in use | Each language has its own SDK, testing approach and worker packaging. Teams running several languages multiply design standards and upgrade work. | Standardize on one or two languages for workflow code. Ask any partner to state which SDK versions and languages the quote covers. |
| Worker pools and environments | Workers need deployment, scaling, task queue design and separate pools for each environment. Every extra environment adds configuration and release steps. | Use one task queue design across environments and keep environment differences in configuration. Confirm how many environments the quote includes. |
| Self-hosted versus Temporal Cloud | Self-hosting adds cluster sizing, upgrades, backups, monitoring and on-call work that the team owns. Temporal Cloud moves service operations to the vendor but adds usage-based charges. | Compare the two options with the same workload assumptions. Ask for a written estimate for each option before choosing. See the cost of ownership topic for the full comparison. |
| Persistence choice | Cassandra, PostgreSQL and MySQL are tested persistence stores with different operating skills. SQLite is for development and testing only, so a production plan needs one of the others. Store sizing and high availability add work. | Pick the store your team already operates well, and confirm the version range supported by your Temporal Server release. Plan backups and failover before the build starts. |
| Advanced visibility on Elasticsearch or OpenSearch | Visibility queries drive a separate search cluster to size, secure, index and monitor. Temporal recommends Elasticsearch or OpenSearch for anything beyond a few workflow executions, and Cassandra visibility is no longer available. | Confirm the visibility store version against the supported matrix. Limit search attributes to the ones operators need, and ask for sizing as part of the quote. |
| SSO and authorization requirements | A self-hosted service allows every request until an Authorizer is configured. OIDC for the Web UI, ClaimMapper rules and namespace role design each add integration and testing effort. | Define namespace roles and identity groups early. Confirm which identity provider you use and whether Web UI access and API access need separate rules. |
| Payload encryption with a codec server | Custom codecs and a codec server encrypt workflow payloads, but they add a service to deploy, scale and secure, plus key management and decryption testing in the Web UI. | Decide early which fields and payloads need encryption. Agree on key rotation and codec server hosting with your security team before the first workflows go live. |
| Compliance evidence | Assessors expect evidence of access control, encryption, backups, change records and upgrade history. Collecting that evidence across the cluster, workers and databases takes planned effort. | Define the evidence list at scoping time and agree which artifacts come from the build. Ask whether the quote includes control documentation. DeployOpen prepares evidence, and independent auditors issue any assessment. |
Project phases and outputs
The sequence moves from agreed scope to a running, verified and handed-over Temporal service, with each phase closing on a named output.
Confirm discovery and workflow selection
We review the processes you want to move, such as cron-driven jobs, queue-based chains or homegrown state machines, and rank them by value and risk. The client receives a written inventory of candidate workflows, the first set to move, and the open questions that affect scope. The phase closes when the sponsor signs off on that list.
Decide architecture and hosting
We compare a self-hosted Temporal Service against Temporal Cloud using your hosting constraints, data residency rules, team capacity and the persistence and visibility stores you already run. The client receives an architecture decision record covering SDK and worker design, databases, visibility store, network placement and authentication approach. It closes when the decision record is approved.
Build non-production environments
We stand up development, test and staging environments that mirror the production topology at the level your risk requires, with worker deployment pipelines and access controls defined from the start. The client receives working environments, infrastructure as code, and access documentation. The phase closes when a test workflow runs end to end in each environment.
Prove the first workflows
We build proof-of-concept versions of the first selected workflows, covering retries, timeouts, activities and failure handling, and run them against realistic failure scenarios. The client receives the working workflows, test results and a list of design changes. The phase closes when the sponsor accepts the proof of concept against agreed criteria.
Build production and deploy workers
We harden the production cluster or Cloud namespaces, finish the workflow code, configure the codec server if payload encryption applies, and deploy workers with monitoring, logging and alerting. The client receives production infrastructure, deployed workers, runbooks and observability dashboards. It closes when the production build passes the agreed acceptance tests.
Verify replay and failover
We run replay testing against workflow history to confirm that code changes stay compatible with running executions, and we test failover of the Temporal Service and worker recovery under load. The client receives a verification report listing results, defects fixed and residual risks. The phase closes when the report is accepted and critical defects are resolved.
Go live and hand over
We move the selected workflows into production in a controlled cutover, monitor the first executions, and then transfer ownership to your operations team with documentation, training and an upgrade plan. The client receives a handover pack, a cutover record and a support model for what comes next. The phase closes when your team accepts ownership in writing.
What usually goes wrong and how to prevent it
Most Temporal projects that stall early do so for predictable reasons. Each risk below should map to a named step in the implementation plan before build starts.
Too many complex first workflows
Teams often pick a large, multi-team process as the first workflow, which stretches design, testing and operations at the same time. Choose one or two bounded processes with clear activities and known failure paths. Record the workflow count and complexity in the plan, and confirm the first scope with the business owner before estimating build effort.
Persistence and visibility stores under-sized
The database and visibility store are often sized from the application's needs rather than from Temporal's load on them. Check the supported versions for your chosen store (Cassandra, PostgreSQL or MySQL for persistence, Elasticsearch or OpenSearch for visibility) and ask for sizing and growth assumptions in writing. Note that SQLite is for development and testing only.
Web UI running without an Authorizer
If no Authorizer is configured, self-hosted Temporal uses the default noopAuthorizer, which allows every API request with no access control. Plan the Authorizer, ClaimMapper and OIDC sign-in for the Web UI as build tasks, not hardening follow-ups. Confirm who may act in each namespace before any environment is shared.
Helm chart and server version mismatch
Helm chart versions below 0.73.1 do not work with server images 1.30 and later. Pin the chart and server image as a matched pair in the plan, and record the upgrade order. Confirm current release versions in the official GitHub releases before the environment is built, since new patch releases are published regularly.
Temporal services exposed to the internet
Temporal services should run on hosts that are not reachable from the public internet, with access limited to trusted internal networks. Plan network isolation and private connectivity for the frontend and Web UI, and add mTLS for internode and frontend traffic. Ask the partner to show the network diagram before any environment is provisioned.
Worker capacity planned without load tests
Worker counts estimated on paper rarely match real activity latency, retry storms or peak volumes. Include load tests against realistic workflow shapes in the plan, with a defined pass criteria for throughput and latency. Budget for test environments and the time to run them, and ask for test results as a deliverable.
One-time and recurring costs
Each row shows a cost line in a Temporal project, who pays for it, whether it is one-time or recurring, and what to ask for in a quote, with Temporal Cloud figures as published starting points.
| Cost line | Who pays | One-time or recurring | What drives it and what to ask for |
|---|---|---|---|
| Discovery and architecture | Your organization, or the partner under a fixed-scope agreement | One-time | Number of candidate workflows, SDK languages and environments. Ask for a written list of design deliverables. |
| Build, testing and first workflow migration | Your team, or the partner under a fixed-scope agreement | One-time | Workflow count, activity complexity, idempotency work and cutover of running executions. Ask for the test plan and migration approach. |
| Training | Your organization | One-time | Number of engineers who write workflows or run workers. Ask what the training covers and who delivers it. |
| Cluster and database infrastructure (self-hosted) | Your organization, in your cloud account or data center | Recurring | Execution volume, persistence store choice and high availability design. Ask for sizing assumptions per environment. |
| Elasticsearch or OpenSearch hosting (self-hosted) | Your organization, in your cloud account or managed service | Recurring | Visibility query volume and retention. Confirm which version your Temporal Server release supports before you size it. |
| Observability tooling | Your organization, through your existing vendors or self-hosted tools | Recurring | Metrics, logs and traces volume from the server and workers. Ask which dashboards and alerts are included in scope. |
| Temporal Cloud actions and storage | Your organization, billed by Temporal Technologies | Recurring | Pay-as-you-go starts at 50 USD per million actions, 0.042 USD per GB-hour active and 0.00105 USD per GB-hour retained (Temporal pricing page). |
| Temporal Cloud support tiers | Your organization, billed by Temporal Technologies | Recurring | Business starts at 500 USD per month with 2-hour P0 response in business hours (Temporal pricing page). Enterprise and Mission Critical are quoted by sales. |
| Internal on-call and upgrade effort | Your platform or operations team | Recurring | Support hours, upgrade frequency and schema changes. Ask whether a support retainer covers upgrades and on-call handover. |
How the work changes by starting point
Scope centers on host layout, the persistence and visibility stores, and the operating procedures your team will own. Docker Compose and Go binaries suit development and small pilots, but production scope adds hardening and operations work.
- Client provides: Linux hosts or VMs inside your network, not reachable from the public internet, plus a persistence store from the tested list (PostgreSQL 13 to 16, MySQL or Cassandra).
- Decisions moved earlier: The persistence engine and version, and whether visibility runs on Elasticsearch or OpenSearch, since the docs recommend it beyond a few workflow executions.
- Scope adds: Process supervision, service placement, TLS and network rules, authorization configuration, and a runbook for each server upgrade.
- Confirm with the vendor: Which container image tags match your target minor release line before you choose a deployment method.
Kubernetes changes the work from building a server to matching chart and server versions. The official Helm charts run each Temporal Server service in its own pods, so scope centers on the chart version, external stores and scaling settings.
- Client provides: An existing cluster on a chosen distribution, storage classes, ingress or load balancing, and a secret management service.
- Decisions moved earlier: The chart version, which is fixed by the server line. Chart versions below 0.73.1 do not work with server 1.30 and later.
- Scope adds: External database and visibility deployment, per-service resource sizing, and worker deployment alongside the cluster.
- Confirm with your platform team: Whether the database is run inside the cluster by an operator or as a managed service outside it.
Temporal Cloud removes server, persistence and visibility build work from the project. Scope shifts to namespace design, identity and network connections, and cost decisions tied to actions and storage.
- Client provides: An account owner, a SAML identity provider for single sign-on, network paths from your workers to Temporal Cloud, and an estimate of workflow volume.
- Decisions moved earlier: Namespace layout and retention, the SLA tier (99.9%, or 99.99% with high availability), and the support tier. Temporal's pricing page lists Business at 500 US dollars per month with a 2-hour P0 response in business hours, while Enterprise and Mission Critical are quoted by sales.
- Scope adds: Worker hosting and deployment, a codec server if payloads are encrypted, and cost modeling against pay-as-you-go action rates, which the pricing page lists from 50 US dollars per million actions.
- Confirm with Temporal: Current pricing, and whether SCIM is required, since the pricing page ties it to the Enterprise and Mission Critical tiers.
Without internet access, every dependency must come from inside your network. Scope grows into a supply chain exercise: images, Helm charts, SDK packages and database software must be mirrored and approved before the build starts.
- Client provides: An internal artifact registry and package mirrors, internal databases with tested backups, a process for importing server releases and patches, and internal DNS and certificate authority services.
- Decisions moved earlier: The release line and patch level to mirror, since each upgrade needs its full dependency set again, and the worker SDK packages your teams will use.
- Scope adds: Offline verification of image digests, a documented upgrade bundle for each minor release, and authorization and mTLS設定, because the default authorizer allows every request.
- Confirm with the vendor: Which Temporal components and dependencies fetch external resources during install, so the mirror set is complete before effort is estimated.
What your team needs to provide
A Temporal scope cannot be priced until the client names the people who make decisions and supplies the facts that drive effort. The first item is a named executive sponsor who can approve scope and budget, and a technical owner who will sign off on architecture and act as the single point of contact for the platform team, security and the business process owners. Without both, the first two weeks of any engagement tend to go to decisions that should have been made before scoping. Next, supply a current inventory of the processes to be moved. For each one, list the trigger, the steps and systems it touches, typical and peak volumes, expected duration (minutes, days or months), how it fails today, and who gets paged. Include cron jobs, queue consumers and any homegrown state machines. Also provide access to the existing code and to the APIs, databases and third-party systems the workflows call, because activity design depends on their idempotency and rate limits. Owners are usually the process owners in the business and the lead engineer for each service.
Platform inputs come from the infrastructure, database and security teams. Confirm the cloud or data center accounts where Temporal will run, the network segmentation between workers, the Temporal Service and the database, and whether services will stay off the public internet, as the Temporal deployment documentation recommends. Choose the persistence store and visibility store from the versions Temporal tests against (for example PostgreSQL, MySQL or Cassandra for persistence, and Elasticsearch or OpenSearch for visibility at scale), and name the team that will operate each one. Decide also whether the hosting model is self-hosted or Temporal Cloud and which support tier you will buy.
Identity and data owners complete the picture. Name the SSO and identity owner who will connect the Web UI through OIDC and, for Temporal Cloud, SAML and SCIM. Name the owner of the authorization model, who will map identity claims to namespace roles. Finally, provide a data classification for workflow payloads and activity inputs, since regulated data may need payload encryption with a codec server and may limit what can be sent to a managed service. Ask the security team to confirm which controls apply before design starts, because the default configuration of self-hosted Temporal allows every API request unless an Authorizer is configured.
Questions buyers ask about Temporal implementation
How much does a Temporal implementation cost, and what drives it?
The cost depends on scope, mainly the number of workflows that move first, the number of worker services and SDK languages, whether you self-host or use Temporal Cloud, and which database and visibility stores you choose. One-time costs cover workflow and worker design, migration, testing and go-live. Recurring costs cover infrastructure, databases, search clusters, upgrades, on-call time and any Temporal Cloud usage or support plan. The Temporal server repository states the MIT license, so the open-source server carries no license fee from Temporal Technologies. DeployOpen does not publish prices. Ask for a quote built from a written scope that lists each cost component and who pays for it.
How long does a Temporal implementation take to deliver?
The timeline depends on scope more than on the platform itself. The main drivers are the number of workflows, how much retry, timeout, signal, query and child workflow logic they need, the number of teams and workers involved, and whether running processes or data must move from cron jobs, queues or another workflow engine. A first production workflow on a small worker fleet is a much smaller project than a multi-team rollout with migration. DeployOpen agrees the schedule in the written scope before work starts, so ask for the milestones and what each one depends on.
Do we need our own engineers and skills to run Temporal?
Yes, your team needs ownership even with outside help. Your engineers should own workflow code, activity idempotency, worker deployments and the business rules for retries and timeouts. For a self-hosted cluster, someone must operate the Temporal Service, its databases, the Elasticsearch or OpenSearch store, and the Helm or Compose deployment, and carry out upgrades one minor version at a time. Check for experience with the Temporal SDK language you choose, Kubernetes or Linux operations, database administration and monitoring. Whether your team can implement alone depends on those skills and on who will own the platform after go-live.
Which persistence and visibility stores does self-hosted Temporal support?
Persistence 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. Advanced visibility supports Elasticsearch 7 and 8, and OpenSearch 2 or later from Temporal Server 1.30.1, as well as MySQL 8.0.17 or later, PostgreSQL 12 or later and SQLite from 1.20. Cassandra visibility was removed in 1.24, and Elasticsearch or OpenSearch is recommended for anything beyond a few workflow executions. Confirm the exact pairing for the server release you plan to run before you commit to a store.
What does Temporal Cloud pricing start at, and what is excluded?
Pay-as-you-go pricing starts at 50 US dollars per million actions, with active storage at 0.042 US dollars per GB-hour and retained storage at 0.00105 US dollars per GB-hour, according to Temporal's pricing page. Standard availability is listed at 99.9%, or 99.99% with high availability. Support add-ons are priced separately: Business starts at 500 US dollars per month with a 2-hour P0 response in business hours, while Enterprise and Mission Critical are quoted by Temporal sales. Implementation work by DeployOpen is billed separately and follows your written scope. Confirm current rates on the pricing page before budgeting.
What must our team provide before a Temporal implementation starts?
Expect to name a technical owner and provide access to the target environment. That means cloud accounts, data center or air-gapped network access, and an inventory of the processes to move, such as cron jobs, queues and homegrown state machines. You will also supply business rules for retries, timeouts and compensation, a decision between self-hosting and Temporal Cloud, identity provider details for SSO, and network and certificate policies. The Temporal deployment documentation says services should run on hosts not reachable from the public internet. Confirm the full list in the written scope, since requirements vary with each environment.
How DeployOpen scopes and delivers Temporal work
DeployOpen plans, builds, documents and supports self-hosted open-source platforms inside your own cloud accounts, data centers or air-gapped networks, and Temporal work follows the same path. We agree a written scope before work starts, so the choice between a self-hosted cluster and Temporal Cloud is settled on paper before any infrastructure is built.
How we scope
- Written scope names the first workflows to move, the business processes they support and the deliverables for each one
- Scope records whether the Temporal Service runs self-hosted or on Temporal Cloud, with the reasons agreed in writing
- Persistence and visibility store choices are listed with their supported versions, so the quote reflects real infrastructure
- Scope states who operates the cluster after go-live and whether ongoing support is handled through a retainer
How we build
- SDK and worker design is documented before code, including task queues, worker scaling and where each worker runs
- Workflows and activities are built with retry, timeout and idempotency decisions recorded alongside the code
- Security controls for self-hosted clusters are set up as part of the build: authentication, authorization, mTLS and network isolation
- Observability is wired in from the start, covering metrics, logs and alerting for the Temporal Service and workers
How we hand over
- Handover includes architecture documentation, runbooks for the Temporal Service and worker deployment procedures
- Tested recovery and upgrade procedures are documented, including the one minor version at a time upgrade sequence
- Workflow versioning and replay testing guidance is delivered so your team can change workflow code safely
- Cost components, one-time and recurring, are documented so your team can track spend after go-live
How we support
- Ongoing support, upgrades and continuous testing are available as retainers once the platform is live
- Support can cover Temporal Service upgrades, SDK upgrades for workers and compatibility checks for Helm charts
- Retainer scope is agreed in writing, so response expectations and included upgrade work are clear before signing
- Your team keeps operational ownership, and we advise on changes to workflows, capacity and security settings as needs change
