I just came across GitHub - temporalio/temporalite: An experimental distribution of Temporal that runs as a single process today.
I was curious if this feasible / intended as a solution for someone who just wants the temporal abstractions around workflow / state machines for small apps that don’t require a full temporal cluster yet. While it is likely a bit heavier than a state machine library, it has an advantage of simplifying scaling in the future.
If this isn’t the right project for that, do you have recommendations for a simplified/minimal temporal install for a single server app?
Can you give more info on your application / use case.
it has an advantage of simplifying scaling in the future.
Imo temporalite or the auto-setup server image are not really intended for scaling purposes as they run all services in the same process. You could have a minimal setup with each temporal service deployed individually, running on k8s via helm chart or on docker via docker compose, which would allow you to have better scaling capabilities. Either way I think you will have to think about scaling of your persistence layer independently of how you deploy your services.
This question is out of curiosity more than a concrete use case.
But let’s say I’m building an operations auto-healing service. It has playbooks that will run against servers and services. These playbooks vary in complexity but could probably get away with a homegrown state machine library that may need replaced down the line.
Alternatively, I was thinking it would be nice to have a minimal version of temporal running on the same host. It would allow one to prototype using temporal sdks while keeping initial setup to a minimum. When it came time to scale the service, the code migration path is greatly simplified.
Those are my thoughts on it at least. I do agree though that managing all the components via k8s or compose is a good route to go as well.