The main purposes for using Temporal are automation flows, especially financial automations and supply chain automations. Our company name is SR, we are a digital-first CPG brand making company, managing over 70 brands, and managing the supply chain in terms of POs, transfer orders, and moving stock between 3PL to Amazon and vice versa involves a workflow process that could include manual or automated steps, and for everything, we use Temporal.

We are just a customer; we directly use it for our internal use cases, building software for our company, and we are not a reseller or any of those modes.

Our workflows are pretty straightforward, not involving multi-step or multi-stage workflows. It's more about making sure it is an automated workflow, not big complex workflows. Therefore, the basic retry mechanisms are solving our needs, and we haven't explored the advanced capabilities yet, as our problems are already resolved.

In terms of scalability, it is the best feature. I did use Camunda in the past for almost three years, and resource constraints-wise, Temporal is much more prudent in doing the work. While Camunda comes with an exceptional UI and more forms, for our use case, pace is more important than actually the UI. Hence, I would say Temporal is working in the right way.

The deployment process is quite straightforward as it provides both Kubernetes and Docker Compose versions, allowing us to run it in ECS containers, and I find it simple for both Camunda and Temporal.

The only area for improvement in Temporal is the UI. I know it is a non-UI first product, but comparing Camunda versus Temporal UI, there is a difference. Moreover, n8n, being a no-code platform, is easier for business people when writing workflows. Hence, we maintain two systems today: n8n for no-code solutions where business automations can be managed, and Temporal for mission-critical systems which cannot fail.

We have been using the solution for roughly about eight months now, not one year.

I do not see performance issues or latency problems with Temporal; the stability largely depends on how we write the code rather than the tool itself. Both Camunda and Temporal are stable as long as we adhere to proper design patterns.

I am tight on schedule today. We can discuss Camunda sometime later, but I can only provide insights on Camunda 7, as I chose Temporal over Camunda 7 for production use.

We haven't engaged any Temporal experts; we've learned everything from their documentation, which I find helpful and clear with examples.

The ROI is apparent in terms of business case automation; previously, a bunch of people filled in data in NetSuite or managed stocks between warehouses and Amazon, but now everything is automated, saving time. We have streamlined processes and saved roughly 300 to 400k in chargebacks, considering our revenue is around 0.5 billion a year.

In terms of pricing, Camunda is indeed costlier than Temporal. The cloud deployment costs differ, and while Camunda 7 can be cheaper due to its integrated setup, comparing latest versions between Temporal versus Camunda 8 is not straightforward. Temporal is faster and cheaper regarding our use cases.

My overall experience with Temporal is rated between 8 to 9, mainly due to a learning curve that only senior developers can navigate effectively, which makes it a bit challenging for junior developers.

We don't have any instances of on-premise, so I cannot comment on that because we are a first company, with all services deployed on cloud infrastructure.

Most of the integration is through RPC or APIs, ensuring all our systems are in cohesion.

We do state persistence to a Postgres instance, and we have modified it to our use case with better indexing. And for fault tolerance, we built a queue and an alerting mechanism that notifies us if any workflows fail after specific failure points so we can act upon it.

On a scale of 1-10, I rate Temporal an 8.

In general, we use Temporal for workflow management. Some of the information is private because I work for a private company.

Temporal allows retryability for different workflows whenever they fail. It helps us to retry workflows without worrying about idempotence and ensures things get done.

Temporal allows retryability for different workflows whenever they fail. It helps ensure idempotence and that things get done.

Retro compatibility needs improvement. Sometimes, when we make new changes to a workflow, it fails if it is not configured properly due to compatibility issues. I wish this could be improved so developers wouldn't have to worry about compatibility.

I have been using Temporal for about a year.

In terms of stability, I would rate it a nine as long as the developer doesn't make mistakes.

It is pretty good in terms of scalability. We haven't had any issues as long as it is in the cloud.

I have not contacted their support team directly, but when I read through their blog posts and see the responses, they seem to be doing pretty well.

I used RabbitMQ in my personal projects before using Temporal.

The initial setup is of medium complexity.

Temporal is a pretty good product for workflow management.

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 needed to implement different workflows for various processes, each involving distinct steps. We used these workflows to handle large data flows or complex operations within our system. We employed them to limit rates, as it was the simplest solution. Furthermore, we implemented some cron jobs, not because they were required but because we wanted to avoid excessive zooming.

It is fairly easy, though it has some undefined aspects if you're unfamiliar with it. For instance, you need to properly define your functions and handle various small issues that can arise. It's easy to get started and user-friendly. There are some internal challenges. For example, I initially missed some error handling and connectivity issues, which led to problems because I implemented things incorrectly.

I don't like the limitations on data flow, particularly the difficulty of passing large amounts of data between different activities. I encountered issues with this and explored various approaches. I decided to store the data in files, but there were other methods. This was redundant because it added complexity to the implementation, making it more challenging to manage.

I have been using Temporal for about a year.

Due to an overload on our cluster, we encountered some problems. We started too many tasks simultaneously. Initially, we attempted to run many tasks at once, but this approach caused issues.

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

The system has good scalability, though it does have some limitations. For instance, Postgres handles scalability well up to a certain point, typically around eight to ten instances. Using a NoSQL database might address some scaling issues more effectively. Postgres was sufficient, and we could work within its constraints.

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

You can use it for free if you want.

In most cases, you don't need extensive prior knowledge to use this technology; the documentation is usually sufficient. It was likely my mistake for not understanding the problem correctly, even though it was logically straightforward. Fortunately, we had an experienced developer on our team who helped me identify some best practices.

I recommend this technology even to large tech companies. It’s pretty substantial and impactful. I suggest reading the documentation more carefully, as it affected my experience.

Overall, I rate the solution an eight 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.

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.

I use it to handle messages from the WhatsApp API. There is a product in my company that uses that API, and Temporal helps us debug and handle retries about the messages we receive, persisting the delivery of the message to the final client.

I like the inner retry system that it has, as a developer. The availability it provides to our products is great. When a micro service crash, Temporal handles the retry by itself. It helps a lot in our company and is by far the best thing Temporal has created.

I think people need to have some experience, at least with event-driven design. When someone tries to understand the signals, queries, and updates, it becomes a little challenging if they haven’t worked with webhooks or event sockets. But if someone already knows about event-driven designs, it’s pretty simple.

Sometimes it scales kind of badly, but it depends on the process of our products. If we have too many signals in a workflow, we might need 50 or 60 pods of the same worker. But this doesn’t happen with every worker; it just happens in some special use cases.

The scalability is great, but could be better.

We needed to change Temporal's database from Postgres to Cassandra to handle it more cheaply for our infrastructure. We do not use Temporal Cloud; we use Temporal Open Source. Cassandra DB was the best choice because it was cheaper. The problem with Postgres was the only problem we faced. But besides that, it has been great since the start.

I have been using it since January 2023. I’ve been using it every day since.

One time, we had a problem with the database. Our PostgreSQL queries from Temporal reached the maximum connections at the same time, and then Temporal’s cluster crashed. It was the only time, and it was a problem with our infrastructure. When we changed it to Cassandra, it never happened again.

I would rate the stability a nine out of ten.

It’s working fine in my current company. We have about three million workflows running at the same time. Sometimes it scales kind of badly, but it depends on the process of our products. If we have too many signals in a workflow, we might need 50 or 60 pods of the same worker. But this doesn’t happen with every worker; it just happens in some special use cases. In general, I think it’s great but could be better.

I would rate the scalability an eight out of ten.

I haven’t faced another challenge besides scalability. We drive around five million events in a small day.

I never needed the support, but sometimes I use the community to speak with them.

The initial setup is easy. I didn’t have any problems deploying it in production or on the devs’ local host. It was pretty great for the devs in general. I think it’s pretty great.

Our project was designed in Temporal. It started with Temporal, so we didn’t have any problems before.

We handle on-premises, and we participate in Temporal community.

There’s a return on investment and it’s worth the money.

Temporal OSS is expensive in infrastructure, but it brings back the reliability that companies need.

I would recommend it to other people. Try Temporal Cloud because on-premise is kind of expensive.

Overall, I would rate it a nine out of ten.

We use Temporal for several purposes. One is for scheduling purposes, where we have workflows that must run at regular intervals or over long durations. Another involves triggering specific events, like in a video processing pipeline, where processing begins as soon as a video becomes available. We also use it for ETL purposes, where once data is available in the data store or warehouse, Temporal triggers the necessary analytics processing. Different teams also define and use the tool based on their specific needs.

From my experience with the tool, I think its best feature is fault tolerance. If an issue occurs, it can be retried from the last successfully processed step without reprocessing the same message. This gives us confidence that completed events won't be retried unnecessarily, even in case of failure. Additionally, it offers a great dashboard and monitoring features, allowing us to see if and where any failures occur, and we can easily retry or replay events to identify issues. Another strong point is that Temporal stores all events in a database, handling everything independently. This feature makes it easier to debug and track logs as needed.

The tool is easy for a beginner to learn. The documentation covers activities, workflows, workers, servers, and more. While more examples could be beneficial, the existing resources are good enough to help you get started. There are also YouTube videos available that can provide additional context. The Slack community for Temporal is very active and helpful, similar to Stack Overflow, where you can find answers to a wide range of questions from basic to advanced levels. If you have a unique question, the community is responsive and provides knowledgeable support.

One area where I think Temporal could improve is its dashboard, particularly in event tracking. Currently, the dashboard doesn't show a time-based view of events, meaning it doesn't display when an event started or went through the retry process. If this feature could be added in a future release, it would significantly enhance monitoring capabilities. Other than that, Temporal's overall performance is quite impressive, and we're confident we can migrate to the Temporal workflow.

I have been using the product for two years.

When we started the POC, my team was the only one using workflow management, with around ten people. However, it eventually expanded to the entire company, so the whole engineering team is currently using it. I can't say the exact number of people because it’s a company-wide adoption.

I have talked to Temporal's support team before. They have a Slack channel and community, which I joined. We faced an issue with the scheduling of EventBuild in some time zones. I asked a question there, and they quickly responded to my query and solved my problem. The support team is very active and generally provides the best solutions possible. The community is great and very helpful.

Before the tool, we used Airflow, but it didn't support complex business logic and only worked with Python. We explored options like Cadence and other workflow management or event processing systems. However, after doing a POC, we found that it offered multiple SDKs, allowed us to write complex business logic, and provided a good monitoring dashboard. So, we decided to switch to Temporal and finalized it as our workflow management solution.

Deployment is easy, especially if you're familiar with Kubernetes. We used Helm for the deployment, and it was straightforward to set up the web service, UI service, front end, and everything else. It didn't take much time, and the documentation was helpful, though it could be improved. The documentation sometimes only covers the basics, which might not be sufficient for someone new to Kubernetes. However, for those with experience, the deployment process is smooth. I also created a document to guide others through the deployment process.

The tool's cost depends on how you implement it. If you're running it in-house, using your own infrastructure like Kubernetes, and managing your own database (e.g., Cassandra), the cost isn't different from what you might be paying for other workflow management solutions. However, you may save some costs by consolidating multiple jobs into a single workflow, which can reduce the number of workloads and resources you need.

On the other hand, cloud hosting might be more expensive. We haven't tried cloud hosting, so I can't provide specific details on that, but it's something to consider if you're looking at cloud-based options.

If you're considering using the tool for the first time, my advice would depend on your specific use cases. If your needs are simple, with no long-running processes, and retrying the same event without issues is acceptable, you might be fine using alternatives. However, if your business logic is complex, especially if you need to ensure that once an event like a transaction is processed, it should not be retried, then Temporal would be a better choice.

Just note that while it's great for these purposes, adding something like a DAG implementation would enhance its usability even more. But overall, Temporal is one of the best options for complex and long-running processes.

Overall, I would rate it around seven to eight out of ten. It solves many problems, like availability, consistency, retry logic, and offers a good dashboard. However, the reason for not rating it higher is due to the documentation and event graph, which could use some improvement. While the documentation is great, it could be more detailed, with more examples, and the server deployment can be tricky for those unfamiliar with it. Additionally, a more advanced monitoring tool, such as a visual graph showing the workflow's progress and where any failures occurred, would be a valuable enhancement.

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.

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.

My friend and I are building an online software as a service platform that uses Temporal extensively. One of my use cases is integrating Keycloak, a single sign-on solution that sends events for bootstrapping organizations and users. I've created an open-source plugin or module that anyone can download and use in their projects, published on GitHub. Another use case is bootstrapping cloud-native solutions. You can write code to initialize the whole solution, defining all steps needed in a serialized fashion. Temporal runs through all sequences, workflows, and activities that need to be processed.

What I like best about Temporal is its durable execution, which means you don't need to write many boilerplate code for critical pieces, especially for retries. It also has great observability and a nice dashboard to see issues without digging into logs. The interface for viewing activities is excellent, with good tracing that shows how long activities took and what ran, making it almost perfect for debugging.

While the tool can be a bit daunting initially, especially if you're not used to async programming models, it's generally a pleasure. There's always room for improvement, though. I've noticed some limitations with the .NET SDK regarding dynamic workflows, but this might have been improved in recent versions. Overall, I think Temporal could be more open about implementing features in a more—.NET-friendly way, especially in how you add workers and clients.

I have been using the product since November last year.

Stability-wise, I'd rate the solution an eight out of ten.

I've contacted the support team through the Slack channel for development questions. Their response time is usually within an hour, but it can depend on the time difference as they're based in Washington.

Setting up Temporal is easy for development —you just run one command. However, depending on your requirements, it can be more challenging for test or development environments. The solution isn't a one-size-fits-all solution. For smaller-scale deployments, it's not too hard. You can use Helm charts for Kubernetes, which only needs a Postgres database. My friend deployed it without much trouble. For larger-scale operations, with millions of operations, you need to use Cassandra DB with Elasticsearch, which requires a lot of resources.

The tool is open source under the MIT license, so there are no hidden fees. You can freely use everything on their GitHub and Docker images.

Overall, I'd rate Temporal a nine out of ten. I would recommend it, especially for bigger organizations or those with more async models of doing things. It might not be suitable for small companies.