If you’re evaluating Temporal for a key workload, an important step in the process is to understand the total cost to operate your application and Temporal. In this post, we break down which costs you should consider for self-hosting Temporal versus Temporal Cloud. We also provide cost estimation strategies for Temporal Cloud.

What we cover in this post

Before we dive into costs, we should clarify which costs we’re referring to. Temporal is comprised of two parts: the Workers that host your application and the Service. In this post, we break down the costs of the Service only. That’s because your Worker costs remain the same regardless of whether you self-host or use Temporal Cloud. Your Workers are an integral part of your own application—always hosted, deployed, and managed by you.

Self-hosting Temporal requires running all the components of the Temporal Service (a minimum of seven components) in addition to the Workers. Temporal Cloud delivers a fully-managed Temporal Service, packaged with a custom persistence layer for optimized performance, services, and support.

Cost considerations for self-hosting Temporal

For self-hosting Temporal, you need to account for the costs of compute infrastructure, a sophisticated tech stack, hardware, and operational resources. Here’s a breakdown of what goes into a self-hosted Temporal Service:

1. Sophisticated tech stack: The Temporal Service is composed of a collection of distinct services: History, Matching, Frontend, Internal Worker, and Web Tier. Each service must be scaled, tuned, and optimized correctly. Underlying all the services is a data persistence layer. You can use Postgres or MySQL for the data persistence, or if you require greater scale, Cassandra. Customers often choose to run Elasticsearch in the cluster as well. For each service, you must provision network security, authentication, encryption, integration into your IDP, and so on. You should factor in the costs of running and supporting each service.

2. Hardware: You must procure and pay for the hardware for each service. The services are all horizontally scalable to handle extremely large workloads. You need to account for the size, memory, CPU, and IO of each.

3. Operational resources: To estimate operational costs, we recommend starting with your SLA. What uptime does your business require of your applications? How does the platform need to behave to deliver on that SLA? Then you can break down the costs as follows:

   • Cost of downtime based on the SLA: If your SLA is 99%, factor in the cost to the business if the use case is down 1% of the time. For some use cases like order management, downtime causes lost revenue. For other use cases, revenue is not impacted.
   • Infrastructure and testing required ro reach the SLA: you must factor in the redundancy, planning, testing, and continuous optimization as you bring more workloads to production. Include the infrastructure for non-production environments as well.
   • Updates: it’s critical to keep on top of security updates and software patches. Remember to consider operating systems, platform, and Temporal updates.
   • Disaster recovery: consider cloud service disruptions and whether you need a strategy to maintain uptime.
   • 24/7 operational center: you must have an on-call team to handle issues across the stack.

Cost considerations and pricing for Temporal Cloud

Temporal Cloud’s pricing is consumption-based, so you pay only for what you use, as well as a support fee. All the hardware, infrastructure, and operational costs are abstracted away, and you just need to think about what your Workflows are doing.

Here’s how pricing breaks down:

• Actions: actions are the smallest units of “durable execution” that make up your Workflows. An action is recorded each time an event happens like starting a Workflow, starting a Timer, and sending a signal. Actions are priced at $25 per million, rated as you consume them. You can tune your Workflow code to increase efficiency, and our services team often works with customers to accomplish this and optimize costs.

• Storage: storage is generally a very small percentage (3-5%) of the total bill. There are two types of storage with different pricing: Active storage: storage for running Workflows that are continuing to grow and add more events, priced at $1 GB-day. Retained storage: closed storage, stored in a colder and less expensive way, priced at $0.01 GB-day.

• Support: the minimum support fee is $200 per month. This covers break/fix support, but it also covers unlimited services. That means a dedicated Solutions Architect and unlimited access to: onboarding, design reviews, code optimization, best practices, and more.

Estimating the cost of Temporal Cloud

We can provide a relatively accurate estimate of cost based on your use case. Use cases can be bucketed by size, into the following categories. Note that in addition to the costs below, you will pay a fixed monthly support fee starting at $200 per month.

• Small, <$25 per month: modest to transient throughput use cases like development and testing, automation and orchestration, and human-in-the-loop. The cost equates to 1 million actions per month or less.
• Medium, <$1,000 per month: use cases with steady or burst throughput like transaction and order systems, infrastructure automation, CI/CD, and batch processing. The cost equates to <40 million actions per month.
• Large, <$10,000 per month: use cases with sustained throughput like data processing, national retail order systems, KYC, and fraud detection. The cost equates to <400 million actions per month.
• Extra Large, $20,000+ per month: use cases with web scale, like social media, some SaaS platforms, and global applications. The cost equates to 1 billion or more actions per month.

The logical next question is: how do you know how many actions per second your workload will produce?

If you’re currently self-hosting version 1.17 or later, you can access the Actions metrics associated with your self-hosted Service through the metrics endpoint. The Temporal Service produces Actions metrics that can be reported or queried by Prometheus. An example PromQL command to capture Actions metrics for the past 30 days is:

Sum (increase(action{service_name=“frontend”}[30d]))

If your application isn’t running with Temporal, you must break down the processes. How many steps does it have? How long does a single execution take? Does it sleep and wake up later? You can use this pricing calculator for a general estimate. Ultimately, you should reach out to us for the most accurate estimate. We can test your workload in Temporal Cloud and give you a highly accurate number.

Additional considerations: upfront costs and scaling

In addition to costs, you should consider the timing of your investments and how your expenses will change as your workload grows.

When self-hosting Temporal, you must invest a large sum upfront to set up your infrastructure. As a result, you must get budget approval sooner. When your workload grows, you need to increase capacity on a stepwise basis. Often, you must over-provision your infrastructure to accommodate potential spikes in traffic or future growth.

The investment curve looks different for Temporal Cloud. Due to the consumption-based pricing model, the upfront investment is zero, and you only pay for the capacity and storage you use. Your costs increase directly in proportion to your usage, and you don’t need to over-provision or pay for idle capacity.

Next steps

For a more detailed discussion on pricing, we recommend watching the cost estimation webinar. If you have any questions or would like an estimate, you can contact our team here.

This post is part of a series about Temporal Cloud. Check out the other posts below:

• Higher throughput and lower latency with Temporal Cloud custom persistence layer
• Exploring Temporal Cloud Automation Features
• High availability and disaster recovery with Temporal Cloud
• How to migrate your self-hosted service to Temporal Cloud