Serverless Workers

This page covers the following:

• What is a Serverless Worker?
• How Serverless invocation works
• Worker lifecycle
• Compute providers

What is a Serverless Worker?

A Serverless Worker is a Temporal Worker that runs on serverless compute instead of a long-lived process. There is no always-on infrastructure to provision or scale. Temporal invokes the Worker when Tasks arrive on a Task Queue, and the Worker shuts down when the work is done.

A Serverless Worker uses the same Temporal SDKs as a traditional long-lived Worker. It registers Workflows and Activities the same way. The difference is in the lifecycle: instead of the Worker starting and polling continuously, Temporal invokes the Serverless Worker on demand, the Worker starts, processes available Tasks, and then shuts down.

Serverless Workers require Worker Versioning. Each Serverless Worker must be associated with a Worker Deployment Version that has a compute provider configured.

To deploy a Serverless Worker, see Deploy a Serverless Worker.

How Serverless invocation works

With long-lived Workers, you start the Worker process, which connects to Temporal and polls a Task Queue for work. Temporal does not need to know anything about the Worker's infrastructure.

With Serverless Workers, Temporal starts the Worker.

Temporal's Worker Controller Instance invokes a Serverless Worker when Tasks arrive on a Task Queue with a compute provider configured.

The invocation flow works as follows:

1. A Task arrives on a Task Queue that has a compute provider configured.
2. Temporal's internal Worker Controller Instance (WCI) service detects that no Worker is polling the Task Queue.
3. Temporal uses the compute provider configuration to invoke the Serverless Worker. For example, calling AWS Lambda's InvokeFunction API.
4. The Serverless Worker starts, creates a Temporal Client, and begins polling the Task Queue.
5. The Worker processes available Tasks until the invocation deadline approaches.
6. The Worker gracefully drains in-progress work and shuts down.

Each invocation is independent. The Worker creates a fresh client connection on every invocation. There is no connection reuse or shared state across invocations.

Worker lifecycle

A single Serverless Worker invocation has three phases: init, work, and shutdown.

The shutdown deadline buffer controls when the Worker stops polling, and the Worker stop timeout controls how long the Worker waits for in-flight Tasks to finish before shutdown hooks run.

During the init phase, the Worker initializes and establishes a client connection to Temporal.

During the work phase, the Worker polls the Task Queue and processes Tasks.

During the shutdown phase, the Worker stops polling, waits for in-flight Tasks to finish, and runs any shutdown hooks (for example, OpenTelemetry telemetry flushes). Shutdown begins before the invocation deadline so the Worker can exit cleanly before the compute provider forcibly terminates the execution environment.

Tuning for long-running Activities

If your Worker handles long-running Activities, set these three values together:

• Worker stop timeout > longest Activity runtime. Gives in-flight Activities enough time to finish after polling stops.
• Shutdown deadline buffer > Worker stop timeout + shutdown hook time. Ensures the drain and any shutdown hooks complete before the compute provider terminates the environment.
• Invocation deadline > longest Activity runtime + shutdown deadline buffer. Set on the compute provider to give each invocation enough total runtime.

For example, if your longest Activity runtime is 5 minutes, and your shutdown hooks take 3 seconds to run, set the Worker stop timeout to more than 5 minutes, and the shutdown deadline buffer to more than 303 seconds (5 minutes + 3 seconds). Set your invocation deadline to at least 10 minutes and 3 seconds (5 minutes + 303 seconds).

The Worker stop timeout controls how long the Worker waits for in-flight Tasks to finish after it stops polling. The shutdown deadline buffer controls how much time before the invocation deadline the Worker stops polling for Tasks.

Raising only the shutdown deadline buffer makes the Worker stop polling earlier, but does not give in-flight Tasks any more time to complete.

Raising only the Worker stop timeout does not make the Worker stop polling earlier, which means the compute provider might terminate the Worker before the full stop timeout completes. In-flight Activities then do not get the full stop timeout to finish, and the shutdown hooks may not run.

Compute providers

A compute provider is the configuration that tells Temporal how to invoke a Serverless Worker. The compute provider is set on a Worker Deployment Version and specifies the provider type, the invocation target, and the credentials Temporal needs to trigger the invocation.

For example, an AWS Lambda compute provider includes the Lambda function ARN and the IAM role that Temporal assumes to invoke the function.

Compute providers are only needed for Serverless Workers. Traditional long-lived Workers do not require a compute provider because the Worker process manages its own lifecycle.

Supported providers

Provider	Description
AWS Lambda	Temporal assumes an IAM role in your AWS account to invoke a Lambda function.