A Worker is a service that does the following:
- Hosts executable Workflow and/or Activity code. (Either can be hosted independently)
- Listens to Task Queues via long polling.
Workers must have access to any resources needed to execute the actions defined in Activities, such as the following:
- Network access for external API calls.
- Credentials for infrastructure provisioning.
- Specialized GPUs for machine learning utilities.
If you need to process work sequentially on the same machine, the Go SDK also offers a Sessions API.
See example Worker code for:
In our tutorials, we show you how to run both the Temporal Server and one Worker on the same machine for local development.
However, a typical production Temporal deployment will have a fleet of Workers external to the main Temporal Server cluster. These can be independently managed by different developer teams, each registering their own sets of Workflows and Activities.
Temporal Server itself has internal workers for system workflows. But this is not visible to the developer.
The external nature of Workers works very well for data privacy concerns, because the Temporal Server (including our managed Temporal Cloud version) doesn't run any Workflow or Activity code on its machines. It is solely responsible for orchestrating state transitions and dispatching messages to the next available Worker.
While data transferred in the event histories is secured by mTLS, by default, it is still readable at rest in the Temporal Server.
To solve this, Temporal SDKs offer a Data Converter API that you can use to customize the serialization of data going out of and coming back in to a Worker, with the net effect of guaranteeing that the Temporal Server cannot read sensitive business data.