Temporal cost of ownership: self-hosted vs Temporal Cloud

What this comparison covers and who decides

This page compares the total cost of running the open-source Temporal Service yourself with the cost of using Temporal Cloud, the managed service sold by Temporal Technologies. The Temporal server is licensed under the MIT license according to its GitHub repository, so the software itself carries no license fee. The cost difference comes from the infrastructure, databases, search storage, people and support that each model requires. The short answer is that the cost model is usually built by the platform owner with an outside party that has run both options, and the decision turns on workload volume, in-house staffing and compliance constraints.

The work is usually triggered by one of three situations: a first production Temporal deployment, a pilot whose workflow volume is growing, or a planned move from one hosting model to the other. Each trigger changes which costs matter most. A first deployment needs a view of setup effort and the skills to operate persistence and visibility stores. A growing pilot needs projections of action volume and storage. A move between models needs a plan for running workflows during the cutover.

Before you request a quote, confirm who on your side owns the cost model and who will be on call for the self-hosted cluster. Ask whether your data residency and access rules allow a managed control plane, because that answer can remove one option before pricing starts. The Temporal deployment documentation also expects services to run on hosts that are not reachable from the public internet, so network placement is a cost input in its own right.

What the cost comparison includes

The cost comparison produces a model and a written recommendation that your team can test against your own workload. It is not a purchase proposal or a vendor contract, and it does not commit you to either option.

Workflow and environment inventory

We list the workflows, activities, namespaces and environments you plan to run, with rough execution volumes, retention needs and peak periods. Every later cost line depends on this inventory, so it is the first thing to validate with your engineering leads. Gaps here produce a model that looks precise but tests the wrong load.

Self-hosted infrastructure cost model

This card covers compute for the frontend, history, matching and worker services, plus the network and load balancing they need. We model each service as a separate cost line so you can see what scales with volume and what stays fixed. Ask your platform team which Kubernetes or VM baseline they already pay for, because shared capacity changes the answer.

Persistence and visibility store costs

We price the persistence store you choose (Cassandra, PostgreSQL or MySQL, within the versions Temporal tests) and the advanced visibility store (Elasticsearch, OpenSearch or a supported SQL database). Confirm which versions your organization supports, since Temporal's compatibility lists differ by store and server release. Visibility sizing is often the line item teams underestimate.

Observability, backups and on-call staffing

This card covers metrics, logs, alerting, backup and restore testing for the persistence and visibility stores, and the people who respond to incidents. Staffing is usually the largest recurring cost in self-hosting, so the model should state who is on call, for how many hours, and what skills they need. Ask whether existing monitoring and backup tooling can be reused.

Temporal Cloud usage model

We model Temporal Cloud cost from billable actions, active storage and retained storage, using the rates on the current pricing page. We then add the support tier you would need, since response times and SSO or SCIM availability differ across tiers. Validate every rate against the pricing page on the day of the quote, because the rates can change.

Written recommendation and assumptions

The output is a recommendation that names the option we consider better for your workload, with each assumption written out and a sensitivity note for the inputs most likely to move. Assumptions cover volumes, retention, staffing and security requirements such as network isolation and authentication. Each assumption is a question you can challenge before any decision is taken.

Decisions you must make

Several inputs belong to your organization, not to us: data residency, acceptable provider dependency, who owns on-call, the required availability target and the support response you need. We list each decision with the option set, the information it depends on and the person who should own it. Unresolved decisions are marked clearly in the recommendation.

What drives the cost of each option

Each row names a driver that changes the bill or the effort, shows how it affects self-hosted Temporal and Temporal Cloud, and says how to keep it down.

Driver	Why it matters	How to keep it down
Action volume and retries	Temporal Cloud meters billable actions, and the pay-as-you-go rate starts at 50 US dollars per million actions (Temporal pricing page). Retries and polling add actions in Cloud. Self-hosted, the same volume adds database writes and worker and server capacity that you pay for.	Measure actions per workflow, not only workflows per day. Tune retry policies and timeouts, batch activities where it is safe, and avoid tight polling loops in workflow code.
Workflow history size and retention	Cloud bills active storage at 0.042 US dollars per GB-hour and retained storage at 0.00105 US dollars per GB-hour (Temporal pricing page). Self-hosted, large histories increase database storage, backup size and replay time on workers.	Keep payloads small and store large data in external systems with references. Set retention per namespace to the business need and confirm the retention period for closed workflows with your team.
Visibility query load and volume	Elasticsearch or OpenSearch is recommended beyond a few workflow executions (Temporal visibility docs). Self-hosted, that means a separate search cluster to size, patch and back up. Heavy list and search queries also add load on the Cloud side through usage.	Limit search attributes to those you query. Avoid polling visibility APIs for status and use workflow queries or signals instead. Confirm sizing with a load test before go-live.
Number of environments and namespaces	Each environment in self-hosted Temporal needs its own cluster or namespace setup, database and monitoring, multiplying fixed infrastructure and operations work. In Cloud, each namespace and environment adds storage and action use, and may raise the support tier you need.	Share non-production environments where isolation allows it. Keep production separate. Ask a Cloud quote to price each namespace you plan to run.
High availability requirements	Temporal Cloud lists a 99.9% SLA, or 99.99% with high availability (Temporal pricing page). Self-hosted, meeting a similar target means redundant frontend, history and matching services, a highly available database and a resilient visibility store, all paid for in hardware or cloud capacity.	Define the availability target per workflow type before choosing a model. Ask the vendor which SLA and high availability option each plan includes in writing.
Support tier	Temporal Cloud Business starts at 500 US dollars per month with a 2-hour P0 response in business hours. Enterprise and Mission Critical are quoted by sales and offer 30-minute or 15-minute P0 response around the clock (Temporal pricing page). Self-hosted support depends on your staff or a retainer.	Match the tier to the hours your workflows must run and the response your on-call team needs. Compare it with the cost of an in-house on-call rota for the same hours.
Compliance evidence needs	Self-hosted, you produce the evidence for access control, encryption, logging and change management yourself, including the Authorizer, mTLS and network isolation the security docs describe. Cloud shifts part of the infrastructure evidence to the vendor, but you still document how your workflows and data are controlled.	Ask the vendor which security reports and controls it can provide for your review. Confirm with your assessor which evidence they expect from you in either model before you size the team.
Internal skills available	Self-hosted Temporal requires people who can run the server, databases, search store, Helm or other deployment tooling and upgrades one minor version at a time. Cloud reduces that work but still needs staff for workflow design, worker deployment and incident handling.	Inventory the skills in your platform and database teams before choosing a model. Price training or a support retainer for any gap, and include the on-call hours in the comparison.

How the cost work is run

The sequence turns a workload profile into two comparable cost models, tests which assumptions move the answer, and ends with a decision memo and the inputs a quote needs.

Collect the workload profile
We gather planned workflows, expected execution counts, activities per execution, retention requirements and the visibility queries teams need to run. Your team supplies the numbers and owners confirm them. The step closes with a signed workload sheet that both cost models will use as their single set of inputs.
Design the two reference architectures
We draw the self-hosted reference design, covering the server services, persistence store, advanced visibility store, environments and network zones, alongside a Temporal Cloud design covering namespaces, regions and worker placement. Each design lists the components that exist in one model and not the other. The step closes with agreed diagrams that show every component to be costed.
Build both cost models with stated assumptions
We price each component in both models, separating one-time work from recurring spend. The self-hosted model covers infrastructure, database and search capacity, upgrades, backups and on-call. The Temporal Cloud model covers action and storage usage, support tier and worker infrastructure. Every assumption is written down with its source. The step closes with two models and an assumptions register.
Review staffing, on-call and skills
We walk through the people side with your platform, database and operations leads. We confirm who would run upgrades, respond to pages, own backups and cover Temporal skills, and whether those people already exist on your team. Staffing is often the largest and least visible line, so the review records each role as existing, added or contracted. The step closes with a staffing table agreed by your leads.
Test sensitivity to the main drivers
We vary the inputs that most often change the outcome, such as execution volume, activities per execution, retention period, visibility query load and support tier, and record where the cheaper model changes. The output is a sensitivity table and a short list of the thresholds where the decision flips. Your team reviews the ranges to confirm they reflect realistic growth.
Produce the decision memo and quote inputs
We write a decision memo that states the two models, the assumptions behind each, the sensitivity results and the open risks, such as upgrade effort or support requirements. We also list the inputs a written quote needs, including scope boundaries and what you would still need to confirm with Temporal. The step closes when your sponsor accepts the memo and the quote inputs are attached to the written scope.

Recurring costs after go-live

This table lists the recurring cost lines for each option after go-live, so you can compare what you would pay for and staff yourself against what Temporal Cloud bills, and confirm current Temporal Cloud rates on the pricing page.

Cost line	Self-hosted Temporal	Temporal Cloud	One-time or recurring
Compute for frontend, history, matching and workers	Hosts or Kubernetes pods for each service, sized to workflow throughput and replica count	No cluster hosts for you to run; confirm what the service includes in your quote	Recurring
Persistence database and backups	Cassandra, PostgreSQL or MySQL compute, storage, replicas and tested backups that you operate	Replaced by active and retained storage charges, quoted per GB-hour	Recurring
Visibility store	Elasticsearch or OpenSearch cluster sized to execution count and query load	No separate visibility line on the pricing page; confirm search terms with sales	Recurring
Monitoring, logging and network	Metrics, logs, load balancing, egress and private connectivity for services kept off the public internet	Network path to the managed endpoint; ask sales about private connectivity options	Recurring
On-call and platform staff	Internal engineers for paging, capacity work, incident response and database care	Lower internal operating load, but your team still owns workers and workflow code	Recurring
Upgrades and chart compatibility	Staff time to move one minor version at a time, run schema steps first and keep Helm charts at 0.73.1 or later for server 1.30 and newer	Confirm which service upgrades the provider performs and which remain with your team	Recurring
Action charges	No per-action charge, but workflow volume drives compute and database load	Billed per million actions, pay-as-you-go from 50 US dollars (Temporal pricing page)	Recurring
Active and retained storage	Covered by database and visibility capacity you provision and monitor	Active at 0.042 and retained at 0.00105 US dollars per GB-hour (Temporal pricing page)	Recurring
Support tier	Internal staff, or a separate vendor support arrangement you negotiate	Business from 500 US dollars per month; Enterprise and Mission Critical quoted by sales (Temporal pricing page)	Recurring

How the comparison changes by starting point

With no existing Temporal, every cost line is new, so the comparison starts from scratch. Self-hosting adds infrastructure and staff lines that Temporal Cloud bundles into its usage and support charges. Confirm these before you compare totals:

Persistence store: choose Cassandra, PostgreSQL or MySQL from the tested versions, and decide who operates and backs it up.
Visibility store: Elasticsearch or OpenSearch is recommended once executions go beyond a few, so budget for it as a separate cluster.
On-call and upgrades: price the on-call rotation and minor-version upgrade work alongside the servers.
Cloud action volume: estimate actions per month from your workflow design, then ask Temporal Technologies for a quote, including the support tier you need.

What usually skews the cost model

Most self-hosted and Temporal Cloud estimates go wrong in the inputs, not the arithmetic. Check each input below against your own workload before comparing totals.

Workflow count instead of action volume

Estimating from the number of workflows misses the metered unit in Temporal Cloud pricing, which is actions, and each retry adds to that count. Model actions per workflow, retry rates and peak throughput, then project them across the planned growth period, not one month. Confirm the action definition with Temporal before you rely on it.

Visibility store and query load

Advanced visibility runs on a separate store, and it is an extra cost in self-hosted deployments that is often left out. Its size and query load grow with workflow executions and with how often operators and dashboards search them. Name the supported visibility backend you will run, and size it from search patterns, not only from storage.

Persistence database and retained history

The persistence database may already exist, but Temporal stores workflow history in it, so it still consumes capacity, backups and licensing or hosting cost. Completed workflows also keep retained storage until their retention period ends, and Temporal Cloud bills that retained storage separately. Size the database for retained history over the retention window you plan to keep.

Unpaid on-call for a stateful cluster

A self-hosted cluster has stateful components, including the persistence store, the visibility store and the Temporal services, and they need on-call coverage with clear escalation. One engineer rarely covers that alone without a rota, upgrade time and a tested restore procedure. Put the staffing hours into the model, including upgrades, which must proceed one minor version at a time.

Security work the noopAuthorizer leaves open

Self-hosted Temporal uses the default noopAuthorizer unless you configure an Authorizer, and that default allows every API request. Adding mTLS, a ClaimMapper, an Authorizer, network isolation and payload encryption takes design, configuration and testing time, which Temporal Cloud largely carries for you. Price that work as one-time and recurring effort, not as a footnote.

Support tier chosen before response needs

Temporal Cloud support tiers differ in P0 response time, hours of coverage and features such as SCIM, and the Business tier starts at a published monthly fee. Choosing a tier from habit or price, without matching it to your incident response obligations, can leave gaps or overspend. Write the response time your on-call process needs, then ask for quotes against that requirement.

What the client needs to provide

The comparison is only as good as the inputs behind it. Start with a workflow inventory: each workflow type that is planned or running, its expected start rate, and its typical retry rate, since both drive action counts in Temporal Cloud and load on a self-hosted cluster. Include how long workflows run, because that determines how much history and storage each one holds. Ask for the peak start rate, not only the average.

Next, define retention and compliance rules for workflow history and payloads. Confirm how long completed history must be kept, whether payloads contain personal or regulated data, and whether data must stay in specific regions. These rules shape storage volume, backup scope and whether payload encryption through a codec server is required. Also record your existing database and search platform standards, such as the PostgreSQL, MySQL or Elasticsearch and OpenSearch versions you already operate, and any hosting and network limits that rule out public cloud endpoints.

Then name the people involved. For a self-hosted cluster, identify who will run it, how many engineers are on the current on-call rota, and whether that rota can absorb database, search and Temporal service pages. Name the security owner for identity and access decisions, the budget owner who will approve recurring spend, and one decision maker who can choose between self-hosting and Temporal Cloud. Confirm who owns the relationship with procurement.

Questions buyers ask about Temporal hosting cost

Does self-hosted Temporal server have a license fee?

No license fee applies to the server itself, because the Temporal server is licensed under the MIT license according to its GitHub repository. Your cost sits in infrastructure (compute, persistence databases, search storage and networking) and in the engineers who upgrade, secure, monitor and respond to incidents. Confirm the license terms of any add-on tooling you combine with it.

What makes Temporal Cloud cost more or less over time?

Temporal Cloud pricing is driven mainly by actions and storage. Pay-as-you-go pricing 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. Action volume follows how many workflow and activity operations your processes run, and storage follows how much workflow state you keep active or retained. Support is a separate add-on: Business starts at 500 US dollars per month, while Enterprise and Mission Critical are quoted by sales.

How long does a Temporal hosting cost comparison take?

The duration is set in the written scope, so this page gives no fixed timeline. The effort usually depends on how many workflow types are in scope, how much history and visibility data you expect to keep, whether your team already runs Kubernetes and the databases Temporal needs, and how quickly your finance and security reviewers can supply inputs. Ask for the scope, deliverables and timeline in writing before work starts, and confirm which inputs your own team must provide.

Can our team do this in-house instead of hiring a partner?

Yes, if your team already has the skills to size and operate the stack. That means experience with a supported persistence store (Cassandra, PostgreSQL or MySQL), Elasticsearch or OpenSearch for visibility, your chosen deployment method, observability, and on-call coverage for a stateful service. Your team also needs to model Temporal Cloud pricing against its own action and storage volumes. An outside review of the cost model is an option if you want a second check before a purchase.

How does Elasticsearch or OpenSearch change self-hosted Temporal cost?

It adds a search cluster that you must size, run, back up and upgrade, with its own recurring infrastructure and staff time. Temporal advanced visibility supports Elasticsearch 7 and 8 and OpenSearch 2 or later from Temporal Server 1.30.1, and Temporal recommends Elasticsearch or OpenSearch for anything beyond a few workflow executions. Cassandra visibility was removed in version 1.24. Confirm supported versions against your target server version, and plan for storage growth, index retention and tuning effort.

What should we confirm with Temporal Technologies before buying Temporal Cloud?

Confirm the current pricing for your expected action and storage volumes, the support tier and response times you need, and which SLA applies (99.9%, or 99.99% with high availability, per the pricing page). Ask whether SAML SSO and SCIM are included in your tier, how Enterprise and Mission Critical support are quoted, and how a move between self-hosted Temporal and Temporal Cloud would be handled. Get the terms in writing, because pricing pages change.

How DeployOpen scopes and delivers this work

DeployOpen models the total cost of running Temporal yourself against Temporal Cloud from a written scope that names your workloads, data stores, staffing model and service levels. The comparison is built from your environment, so the result reflects your choices rather than a generic estimate.

How we scope

The written scope lists the workflows, workers, namespaces and expected action volumes that the cost model will cover.
We inventory the self-hosted components to price, including persistence, advanced visibility, compute, backups and monitoring.
Engagements are fixed-scope, and ongoing support is available as a retainer once the scope is agreed in writing.

How we build

We build a cost model with one-time and recurring lines, and state the assumptions behind each line for your review.
We check persistence and visibility choices against the versions Temporal tests, so the database costs match a supported configuration.
We confirm support tiers, security features such as SAML SSO and SCIM, and availability targets against the current Temporal pricing page.

How we hand over

You receive the cost model in an editable form, with each assumption linked to a named input you can change.
The hand-over covers a recommendation with the trade-offs for self-hosted operation, Temporal Cloud and any hybrid path.
We document the staffing, on-call and upgrade effort your team would carry for a self-hosted option, so the figures can be checked.

How we support

Support covers revisiting the cost model when action volumes, storage needs or pricing terms change.
Upgrade planning for a self-hosted Temporal Service can be included, since minor upgrades and schema steps add recurring effort.
Retainers can cover periodic review of the model against your actual usage, with changes agreed in writing.

Temporal cost of ownership: self-hosted versus Temporal Cloud