Temporal Reviews

We have multiple products and wanted to use Temporal because different business logic was better suited to different programming languages, such as Java and Python. We needed a unified solution to handle this diversity. Netflix, one of our clients, introduced us to Temporal.

We set up an on-premise Temporal server, with Temporal handling the initial setup in our Kubernetes cluster. Another team implemented additional security measures on top of Temporal to enhance security. We developed our authentication system and library to integrate with multiple role-based access control systems.

We use Temporal primarily for orchestration. We deploy products across AWS Cloud, Azure, and on-premise data centers. Temporal helps us centralize the orchestration process. We use the Temporal SDK to implement our workflows and workers in our Kubernetes cluster. Based on user requests from a centralized portal, we trigger workflows, which drive multiple tasks sequentially or concurrently to deliver the desired outcomes.

Temporal solved a major problem for us. Implementing a saga pattern or a workflow management system traditionally requires handling many aspects beyond business logic. These include retry mechanisms, rollback mechanisms, logging, monitoring execution status, and features for pausing or resuming workflow execution. Temporal provides all these features by default, allowing us to focus solely on our business logic while Temporal manages the rest.

The network should consider adding a basic authentication system to Temporal, such as JWT token-based authentication. Temporal doesn’t include these features by default, and while Temporal Cloud might offer them, on-premise users have to build their security systems. This is an area where there is room for improvement.

Temporal terminology can be confusing for new users. A more user-friendly approach or improved documentation could help ease the learning curve. The current documentation often requires users to piece together information from various sources, including existing implementations from other organizations or direct developer support. The documentation needs a significant update. Not all necessary information is available online, and community support is limited. For instance, our security team implemented certain features a year ago, but it included relevant information in their documentation. Improved documentation and better community support would greatly benefit users working with Temporal.

I have been using Temporal for the last one and a half years.

While Temporal is generally stable, improvements could be made in some areas. Temporal UI provides information on execution status; it only shows the latest state and not the history of previous attempts or failures. This limits our ability to diagnose issues without setting up a separate logging system in tools like Splunk or Elasticsearch.

The traceback provided by Temporal isn’t always helpful when working with core areas such as interceptors. For instance, verifying if tokens are correctly attached to headers and linked with requests is difficult.

Another challenge is with SDKs. Temporal uses different approaches depending on the language: for Go and Java, it provides native SDKs, while for Python and TypeScript, it uses a Rust core with wrappers. This division makes it difficult to trace issues in the Rust core from Python or TypeScript, creating a barrier to debugging and development.

I rate the solution’s stability a seven out of ten.

From a scalability perspective, Temporal excels. It allows us to spawn multiple workers and handles task distribution across them efficiently. We don’t need to worry much about load balancing. We build and launch as many containers as needed, pointing to the same Temporal server. Its server is a load balancer and a queue system, making it highly effective for scalable applications.

It would be beneficial if Temporal could simplify scalability by allowing workers to spawn multiple processes within a single container based on a specified number rather than deploying multiple containers. This approach would streamline scalability and reduce the need for additional management from the Jenkins side.

We have around ten to twelve services running on the top of Temporal.

I rate the solution’s scalability an eight out of ten.

We did not find any dedicated support. We had to either raise concerns in their forum or connect to the Slack channel of Temporal and raise concerns in the appropriate channel, such as the Python SDK channel, for Python-related issues. 

They operate in US time zones, and since I am in the Indian time zone, I have to wait until they are online to receive assistance. The support is text-based only, and there is often a delay.

Suppose you have multiple technologies across your portfolio and want to implement business logic. In that case, it’s better to use technologies like Temporal instead of converting all the business logic to a single language. If you’re starting from scratch and the business logic is simple without complex scenarios, using Temporal from the beginning might not make sense because it can be complex and requires heavy infrastructure, which increases costs. Temporal may not be recommended for small-scale projects, but it could be a good fit for larger scales where you’ve already implemented many things in different languages.

Overall, I rate the solution an eight out of ten.

Temporal serves as an orchestration manager for our Mac platform. It allows us to view and manage all the workflows within the application, providing a framework for implementing these workflows efficiently. Temporal itself doesn't store data; our AWS setup handles storage and other functionalities. Temporal offers a platform for orchestration management and provides SDK tools.

Temporal serves as an Orchestration Manager for our microservices architecture. It automates the communication and actions between multiple microservices. With Temporal, we can track workflows' progress, identify failures, and retry actions as needed. It eliminates the need for each microservice. Previously, we had a dedicated microservice for orchestration, but Temporal replaced it seamlessly.

Temporal provides visibility into workflow progress and analytics andsupports scheduled tasks with customizable settings, making it very convenient.

There are areas where Temporal could improve. For instance, calling multiple microservices with Temporal introduces latency due to workflow registration and analytics overhead.

I have been using Temporal for the past year.

I haven't experienced any stability issues or bugs with Temporal. It has been stable and reliable throughout my use, up to version 1.5.

I once contacted Temporal's support team regarding a certificate issue, but it was our mistake. Overall, I was satisfied with the support.

The initial installation and setup of Temporal was straightforward. We needed to generate a certificate and private key, making the process very simple.

If someone asked me whether they should use Temporal for the first time, I'd say it depends on their customer base. If they have few customers, RabbitMQ might be a better choice. However, if they have many customers or an event-driven system, Temporal would be easier to manage and track. For a beginner joining our team, learning Temporal might initially have a moderatelearning curve, but once you get the hang of it, it becomes pretty easy to understand.

I would rate Temporal nine out of ten because it's the best workflow manager I've used.The one-point deduction is mainly for potential improvements and the latency issue that can sometimes occur.

We use Temporal in our company to create child components and complete workflows that are dependent on each other. We also use it for child workflows and employee task orientation.

The most valuable thing about Temporal is that we can create multiple and child workflows. We can segregate work as we want, which is good for work organization. It's also easy to maintain. We're trying to generate and fill PDF forms with custom data, including digital signatures. We call AWS and do all activities through Temporal, like calling and saving data in buckets. We do this because we have a lot of load, with multiple users requesting data. We have two types of users: admin and customer. The admin creates forms, and employees or customers fill them out. When admin gets a form, it's stored in Temporal.

We convert RSA files to PKCS format for integration and have configuration settings. Many libraries help integrate the tool, making it easy to implement in Java and Python.

One issue is that we don't have enough resources in the community to get answers when we face problems. We once had a cross-cluster persistence issue, which we solved using different keys. I think Temporal is good right now, but I'm part of the community and will let you know if I think of any improvements.

We use the cloud version of Temporal. They provide a key that we insert in our files to execute functionality. Our certificate expires in one year, which can cause issues in the product. It would be beneficial if the certificate expiry timeline could be extended to two or three years, as changing it every year is challenging.

 One issue is that workflows without an expiry time can run indefinitely, overloading the server. It would be helpful to have a default timeline that automatically deletes or removes workflows after a month.

I have been working with the product for a year. 

The tool doesn't have any performance issues. 

The solution's scalability is high. 

I haven't contacted support yet. 

Before Temporal, we tried to implement Kafka, but Temporal was better suited to our use cases. We evaluated Kafka but decided to go with Temporal.

The initial setup can be tough for beginners as it's not like simple coding languages. You must understand how functions work, including small things like run methods. I followed the personal document. Three to four people were involved in the deployment. Deployment locally can take one or two days, including all activity checks and finalizing components.

I rate the overall solution a nine out of ten. 

Our team's project is about a service that allows you to hit third-party APIs. Let's say we have multiple products at our company. They will want to hit some third-party APIs for document verification, for which we have some third-party vendors. Instead of them directly hitting their product, we act as a layer in between. They hit our APIs, and then we hit the vendors, ensuring that the response they get is generalized.

Different vendors might have different responses. We give a generic response so that it's easier for them to handle at their end. We have two different modes of operation, namely, sync and async APIs. Async APIs are where we mostly leverage Temporal because async workflows are prone to errors and are not that durable. That's where Temporal comes in. We use Temporal to ensure the durability and scalability of our product.

The solution's most valuable feature is its ability to retry from an interrupted state. I think this feature makes it more popular among developers, and we specifically use and leverage this feature the most in our project.

Temporal doesn't have built-in data storage to store the state of the ongoing execution. We have to configure separate RDS for state management and data storage. Temporal should consider having its own data store so that we don't have to integrate with a third-party data store app.

I have been using Temporal for a couple of months in my company's recent project.

We didn't face an incident where Temporal was down for any reason. The only issue we faced was that we had allocated less storage to the RDS, which Temporal was using to store all sorts of data. Since the storage was less and we had more data pushed, it broke down. However, that had nothing to do with the solution.

I rate the solution’s stability a nine out of ten.

Temporal is a scalable solution both in terms of integration and handling multiple requests. When I spin an activity in a workflow, Temporal can manage it pretty well and store the state of the ongoing code irrespective of how heavy that activity is. In case of a failure, it retries from the current state.

The major challenge we faced was durability. There are instances where an execution gets interrupted, or our service goes down for some reason. Since we mostly use Temporal to interact with third-party vendors, those vendors or endpoints would often be down.

We had to have our own custom retry mechanisms, which come with building Temporal. There was no way to ensure the execution could be durable. The best thing we could do was ask the product to hit that API again.

I would recommend the solution to other users. The main reason why Temporal was built was to have a defined state for microservices. For databases, if we do a transaction, we can be sure either it will succeed or fail. There won't be any state where it's somewhere in between that. Temporal does the same thing for microservices.

Many open-source applications have to implement their own custom logic to ensure things Temporal offers by using an API call to their service using gRPC. This custom logic is heavy, apart from the business logic itself.

Overall, I rate the solution a nine out of ten.

We [my company] use  it to run a large workload. We have a set of security scans we want to perform, and we distribute them over a full day, that’s over 24 hours. We use it to orchestrate all the steps necessary to perform those tests.

It’s essentially an orchestrator. So, we get all those properties we want from an orchestrator. Particularly, we like the fact that the whole process is durable, which is very useful to us. The fact that you can split it up into multiple smaller steps, called activities, and store state at every single activity is something we have made a lot of use of. For example, this allows us, in case of any failures down the road, to stop the process midway and resume it later. That’s another feature that’s been really useful.

We like the fact that it integrates very well with the programming language. It’s not completely transparent; you know you’re using Temporal because you have to import the SDK into the programming language itself. But it’s done in such a way that it’s really easy to write and fits well within the language. Personally, I like that the main abstraction, workflows, allows you to follow domain-driven designs super easily. In your workflow, you can essentially speak your business language and not have to worry too much about Temporal because it’s abstracted away so nicely.

One last feature that’s super useful is that retry policies are built into the Temporal system. For example, if one of your activities fails for multiple reasons, you can configure how you want to handle your failure cases in the activity itself with a retry policy. You can say, “Okay, I want to retry this later,” and configure the cadence. This step is really configurable, it’s built into the system, and it’s something we have made a lot of use of. So, that’s pretty much a big picture summary.

The actual user interface is still in its early stages. It’s very basic. Users don’t really have a complex permission model yet. Users don’t really have ways to automate things like, for example, provisioning the Temporal namespace via Terraform. Users can’t do that yet. Users still have to do it manually.

Another thing I remember is the certificate rotation. Users can’t configure that to be done automatically. Users have to do it manually in each of the Temporal namespaces, which is actually super annoying for us. We’ve been talking with them about whether or not they were going to add a feature that would support that, and they said that it’s in the backlog, and they’re still working on it, but they don’t really have a timeline for it yet.

So, the operations on the interface are still in very early stages. Users can’t really do that many things when it comes to administration. The essential things users can do, but the more convenient things, some of them are lacking. So that’s a downside.

When you run your activities, it would be nice if you would not only see the latest error you get from an activity. When you do an activity, there are retries. Retries happen for various reasons, which means you can execute the same activity multiple times and get different errors. Now Temporal only shows the latest one. It would be nice if it showed all the errors. I’ve been reading a bit about it, and as far as I understand, it’s a limitation of how the system is built. But from what I understood from my colleagues, they talked to Temporal, and they said that there is possibly going to be a way to do that. I’m not sure whether that’s true or not, but it would be really nice. So that’s something that came to mind.

Another aspect of it that I don’t like is that Temporal Cloud is not friendly for smaller users. I wanted to include Temporal in some of my projects, and Temporal Cloud would have been a nice addition because managing the self-hosted cluster, I did not find easy. There’s a lot of setup in doing that. It would have been nice for me to use Temporal Cloud, but the pricing model doesn’t really allow for that. If I remember correctly, there’s $200 customer support fee you have to pay for Temporal if you register for Temporal Cloud, which is obviously way out of my budget for a self-hosted user that just wants to run a few workloads. It would be nice if they made some changes to their pricing model so that not just companies have an incentive to use Temporal Cloud. Because, at the moment, there’s no way for me to do it without having to pay a lot of money.

I have been using it for last nine months now. 

We run quite a lot of volume, so the product is pretty good on that side. Mainly, your scalability will be in your infrastructure because Temporal doesn’t run any workloads. Temporal only stores your state. The processes that are actually running those workloads are your workers, and those are running on your infrastructure and are going to port a queue.

So, basically, if there are bottlenecks in your workload, if they need scaling, it’s a change you would do on your workers. Now, obviously, there’s the question of whether the Temporal cluster itself would scale because if you run a lot of things at the same time, then you’re going to have a lot of writes to the Temporal cluster and a lot of changes to their cloud databases. But we haven’t really had problems with that. They scaled pretty well according to our needs.

For the self-hosted cluster was much slower, but the cloud one has met our demands in terms of scalability.

It’s multiple users and multiple locations now. It’s quite a large volume in our case.

All tech support has the way we interact with them is via Slack. We have a Slack channel in which we talk with them. They’re pretty quick.

They were helpful. There’s nothing really to complain about there. They’ve always helped us whenever we asked them, and they regularly check in to see how we’re doing. If they see issues or weird traffic patterns on their side that they consider not necessarily best practices, they reach out to us. I’ve only had good times with tech support.

I’ve really nothing to complain about the technical support. I just go for it and I’ve only had good experiences with the tech support.

Positive

Some of my colleagues might have used Amazon Workflows, but I haven’t. From what I can gather, they’re fairly similar products, but Temporal turned out cheaper, which was one of the criteria they used to select it.  

There have definitely been some problems we’ve had with it. For us, it wasn’t just take it out of the box and it worked right away. We had to do a lot of configuration to get it working in the state we wanted. It was a lot of back and forth with Temporal.

First, we used the self-hosted version, so you can self-host it yourself. But that didn’t scale too well for us. But we migrated to the cloud at some point.

We mostly worked with it on the cloud, but it wasn’t all good right out of the box, even after we migrated to the cloud. We had certain issues, and some of those issues were because we didn’t know all the features it had to provide. Some of those issues, even Temporal, we didn’t know how to fix because we think they were due to the very large volume of work we were scheduling in a very short amount of time.

In our use case, because we do a lot of work with it every single day, we had to spend quite some time configuring it and getting it to work how we wanted. But that’s not necessarily the case for other user flows that use Temporal and have a very different traffic pattern. Those were much easier to get working well with minimal configuration.

I was not involved in the initial step. I was involved in subsequent steps, which did the transitioning between the self-hosted and the cloud setup, but the cloud setup was already there when I came. I took part in provisioning some new namespaces, but it was mostly ClickOps. From my perspective, getting started with Temporal Cloud was probably more work on the business and product side rather than on the engineering side. I think that on the engineering side, the amount of work you have to do to get your cloud account running is really minimal.

Three resources were involved in the migration process and the setup of the cloud environment.

From maintenance point of view, we have to maintain the workers. But from a maintenance point of view, it’s alright. It’s a SaaS solution, so Temporal do most of the hard work. One maintenance aspect is the certificate rotation. That’s really annoying to do. 

The maintenance for the self-hosted cluster is much more complicated and one of the reasons we’ve migrated. But, that’s also due to the fact that, being a security company, we have to respect strict security guidelines, which means that we have to modify some of the images that they provided because they didn’t respect those guidelines yet. For example, Temporal images aren’t FIPS compliant, and we have to be FIPS compliant.

For us, it ends up being quite costly. But it’s still probably more cost-effective for us to do it using Temporal. So, it’s a bit expensive, and it would be nice if the cost didn’t scale linearly because, at the moment, they have something like $25 per million actions, and then that keeps decreasing given the amount of actions you have, which is okay. But in the end, it’s still linear.

If you build a solution yourself, you will have a lot of maintenance costs, a lot of costs for the engineers involved in doing that. And, specialized resources. That’s the product they’re building, and they’re investing a lot of time with it. So you might not get away with something as reliable.

Now,  unless you need an orchestrator, unless you need durability, for example, if you’re a payment service provider, then you absolutely need that durability. But if you’re just an early startup doing some basic CRUD operations, so you’re at the very beginning, then you probably don’t need the durability. So you definitely have to take into account whether or not you actually need that durability when you decide on the solution.

If this business logic can fail and if that’s a use case we can tolerate, then you probably don’t have to go and purchase Temporal. But if you have a business operation that absolutely cannot fail, we absolutely cannot tolerate the failure; this operation has to run to completion, then you should definitely consider an orchestrator like Temporal.

I might be biased because I really like this technology. I’m not going to go for the ten because of the downsides but Temporal would be a strong eight out of ten, definitely nine. But if they consider improving the weaker points, I would definitely see this as one of the strongest stacks we have currently.

I’d recommend it, but be cautious before going for the tech just because it sounds nice. Users definitely have to lay out their use cases and figure out whether they need an orchestrator in the first place becauses it’s not a Swiss army knife. It’s not a tool that fits every use case. But for our use cases, for example, I definitely recommend it. It's a really good product.

We use Temporal to manage workflows for a client project involving interactions with MongoDB. We needed a framework to manage workflows and set the correct order and timing. We chose Temporal over Azure Functions because it worked better for our needs.

What I like best about the tool is that it's easy to install, especially since it uses JavaScript. It's also easy to set up with Docker, and the documentation is easy to understand.

Configuring workflows can be improved —the solution could offer more options, but it's not a must-have.

I have been using the product for a year. 

I haven't experienced any stability issues or bugs with Temporal. Any problems I encountered were more related to our specific project than the tool itself.

I think Temporal's scalability is very high. While our current project hasn't required much scaling yet, I can see the benefits for future use. I'd rate its scalability as an eight out of ten, mainly because it was easy to implement with Docker. 

In my organization, at least three people used Temporal when I was involved in the project.

I haven't contacted the support. I can manage with the documentation. 

Before implementing Temporal, we struggled with Azure Functions, which was hard to understand and manage. Temporal made it clearer how the workflow would function from start to finish.

Temporal is open-source and free to use, which is great. We didn't have to pay for any premium features.

You need to know Node.js, Express, and Docker to use the tool effectively. Docker is particularly important for easy setup and image mounting.

Overall, I'd give the tool a solid an eight out of ten. It's easy to use and start up, making it simple to begin a project.

I would recommend Temporal to others. My advice would be to clearly understand Docker, as it goes hand-in-hand with using Temporal for setup and implementation. I'd also recommend reading the documentation about creating plugins for Temporal to understand how to build workflows for any project.

We used the solution for integrations. I worked for a company that did international freight integrations, and we had to integrate with a system called CargoWise to help our customers track their containers and shipments. We used Temporal workflows to pull in data and keep everything in sync.

The solution's most valuable feature is its ability to fix things quickly. Suppose there's a bug in the code and the workflow you created in Temporal breaks in production. If we lose that data, the system will be out of sync. With Temporal, you can create and push a patch to production so that the workflow will retry automatically, and you won't lose any data.

We previously faced issues with the solution's patch system. We had to create the patch and put a condition on the code to check if the workflow was patched or not. Then, we needed to push another change to get rid of that patch.

I used Temporal on my previous job for seven to eight months.

In our case, the solution's scalability was pretty good. We used the Temporal Cloud service. Temporal gives you the option to either host it yourself or pay for the service, and we paid for Temporal Cloud. We also had our workers running on Kubernetes. It was pretty good. We had to scale it up a few times, but it just worked fine.

I rate the solution’s scalability an eight out of ten.

We contacted the technical support team many times to ask questions and get help, and they were very good at responding.

Positive

The solution's initial setup was straightforward, but setting up the tokens on Temporal Cloud was difficult. You had to create this token, and they have docs on it. You can install a Docker container that will create a token for you, but it's not production-ready. We had a couple of issues getting that going. However, it was fine after we learned it.

Temporal is worth the money.

One of the reasons we wanted to change to Temporal was to cut costs because our AWS bill was really, really high. We migrated all of our integrations to use Temporal workflows. The savings weren't as big as we initially expected, but they were pretty great from a developer's perspective.

You need to be a software developer or a software engineer to use Temporal. Other than that, its documentation is pretty good. It is a pretty new product. We found it online when we first started working with it. When we thought it would fit our needs, we read the docs and started building the workflows, and it worked.

I would recommend the solution to other users because it's a really good tool. Temporal gets rid of the need to worry about a bunch of things. When coding, I felt like I could focus on the integration itself, and I didn't have to worry that much about making sure things didn't break.

Suppose you have an integration, and you're building it all by yourself. If something breaks in a microservice, the other microservice needs to be ready, and everything needs to be ready to support that error without losing any data. Using Temporal got rid of a lot of that complication.

Overall, I rate the solution a nine out of ten.

We use this solution to power an internal workflow engine we've developed. Currently, it's being used within our company to manage workloads running on the orchestration platform.

Temporal fault tolerance has been beneficial for our critical business operations. It handles scheduled tasks and failures effectively, automatically retrying processes in case of issues. Additionally, our workflows are managed smoothly, with our internal engine providing inputs toTemporal for task execution. As for AI-driven projects, we haven't utilized Temporal in this domain yet.

The most valuable feature is its ability to manage and automate workflows without manual intervention efficiently. This includes handling functions and activities and orchestrating various tasks seamlessly. Temporal's reliability and performance have been exceptional for us, even with thousands of workflows running daily on-premises.

Temporal could be improved by making it more user-friendly for beginners and non-technical staff, ensuring easier integration and usability across different use cases.

I have been using Temporal for the past year and a half.

In my experience, I haven't encountered any issues or bugs. Everything has been working smoothly.

It is very scalable. We can run thousands of workflows simultaneously without any issues, so scalability-wise, it's perfect.

The initial setup of Temporal is straightforward. It's similar to deploying other servers; you must adjust the resources if necessary. Overall, no special knowledge is required.

I would rate it an eight because while it's robust and scalable, once you're familiar with it, there's a learning curve for newcomers due to the complexities involved. Additionally, managing specific errors and concepts can be initially challenging. However, its scalability and open-source nature are significant advantages.