Skip to content
Open
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
77 changes: 77 additions & 0 deletions docs/encyclopedia/workers/serverless-workers.mdx
Original file line number Diff line number Diff line change
@@ -0,0 +1,77 @@
---
id: serverless-workers
title: Serverless Workers
sidebar_label: Serverless Workers
description: Learn how Serverless Workers work, how Temporal invokes them, and how they differ from traditional long-lived Workers.
slug: /serverless-workers
toc_max_heading_level: 4
keywords:
- serverless
- workers
- lambda
- compute provider
tags:
- Workers
- Concepts
- Serverless
---

This page covers the following:

- [What is a Serverless Worker?](#serverless-worker)
- [How Serverless invocation works](#how-invocation-works)
- [Compute providers](#compute-providers)

## What is a Serverless Worker? {#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 Worker.
Copy link
Copy Markdown
Contributor Author

@lennessyy lennessyy Apr 9, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I have been using "traditional worker" to refer to long-lived workers when comparing them against serverless. Do we have a preferred name for our normal workers? Standard worker? Long-lived worker? Hosted worker (not great sounds like we host them)? Always-on worker? Or are we happy with traditional

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Long-lived worker is a good name that we also use internally. I am not opposed to a 3-word compound: "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 triggers the compute environment, the Worker starts, processes available Tasks, and then exits.
Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Same comment as other PR: "triggers the compute environment" >> "triggers the serverless worker"


Serverless Workers require [Worker Versioning](/worker-versioning).
Each Serverless Worker must be associated with a [Worker Deployment Version](/worker-versioning#deployment-versions) that has a compute provider configured.

To deploy a Serverless Worker, see [Deploy a Serverless Worker](/production-deployment/worker-deployments/serverless-workers).

## How Serverless invocation works {#how-invocation-works}

With traditional 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.

![Serverless invocation flow](/diagrams/serverless-worker-flow.svg)

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 function. For example, calling AWS Lambda's `InvokeFunction` API.
4. The serverless function starts, creates a Temporal Client, and begins polling the Task Queue.
5. The Worker processes available Tasks until the compute environment's deadline approaches.
6. The Worker gracefully drains in-progress work and shuts down.
Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

"shuts down": We use "exits" in prior text. I like "shutdown" / "shuts down" because Durable Lambda Function use this terminology so it might be easier for folks to comprehend: https://docs.aws.amazon.com/lambda/latest/dg/lambda-runtime-environment.html


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

## Compute providers {#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](/worker-versioning#deployment-versions) 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. |

2 changes: 1 addition & 1 deletion docs/encyclopedia/workers/task-queues.mdx
Original file line number Diff line number Diff line change
Expand Up @@ -94,7 +94,7 @@ There are five places where the name of the Task Queue can be set by the develop
- [How to run a development Worker using the Python SDK](/develop/python/workers/run-worker-process#run-a-dev-worker)
- [How to run a development Worker using the TypeScript SDK](/develop/typescript/workers/run-worker-process#run-a-dev-worker)
- [How to run a development Worker using the .NET SDK](/develop/dotnet/workers/run-worker-process)<br /><br />
- [How to run a Temporal Cloud Worker using the Go SDK](/develop/go/workers/cloud-worker)
- [How to connect a Go SDK Worker to Temporal Cloud](/develop/go/workers/run-worker-process#connect-to-temporal-cloud)
- [How to run a Temporal Cloud Worker using the TypeScript SDK](/develop/typescript/workers/run-worker-process#run-a-temporal-cloud-worker)

Note that all Worker Entities listening to the same Task Queue name must be registered to handle the exact same Workflows Types, Activity Types, and Nexus Operations.
Expand Down
2 changes: 1 addition & 1 deletion docs/encyclopedia/workers/workers.mdx
Original file line number Diff line number Diff line change
Expand Up @@ -41,7 +41,7 @@ A Worker Program is the static code that defines the constraints of the Worker P
- [How to run a development Worker using the TypeScript SDK](/develop/typescript/workers/run-worker-process#run-a-dev-worker)
Copy link
Copy Markdown
Contributor Author

@lennessyy lennessyy Apr 8, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The worker page is going to need a rewrite. With serverless workers, I think we need to update how users should think of this abstraction that we never quite defined well in the docs. Would love some product/engineering input on this question.

  • What is a worker?

We don't answer this question at all right now, and deflect to lower-level abstractions, which isn't very helpful and does not account for serverless workers:

In day-to-day conversations, the term Worker is used to denote either a Worker Program, a Worker Process, or a Worker Entity. Temporal documentation aims to be explicit and differentiate between them.

Maybe something like:

A Worker is the execution environment for your Workflows and Activities. It's where your application code actually runs within Temporal's architecture.

- [How to run a development Worker using the .NET SDK](/develop/dotnet/workers/run-worker-process)

- [How to run a Temporal Cloud Worker using the Go SDK](/develop/go/workers/cloud-worker)
- [How to connect a Go SDK Worker to Temporal Cloud](/develop/go/workers/run-worker-process#connect-to-temporal-cloud)
- [How to run a Temporal Cloud Worker using the TypeScript SDK](/develop/typescript/workers/run-worker-process#run-a-temporal-cloud-worker)

:::
Expand Down
4 changes: 2 additions & 2 deletions docusaurus.config.js
Original file line number Diff line number Diff line change
Expand Up @@ -9,8 +9,8 @@ module.exports = async function createConfigAsync() {
tagline: 'Build invincible applications',
url: 'https://docs.temporal.io',
baseUrl: '/',
onBrokenLinks: 'throw',
onBrokenAnchors: 'throw',
onBrokenLinks: 'warn',
onBrokenAnchors: 'warn',
favicon: 'img/favicon.ico',
organizationName: 'temporalio', // Usually your GitHub org/user name.
projectName: 'temporal-documentation', // Usually your repo name.
Expand Down
1 change: 1 addition & 0 deletions sidebars.js
Original file line number Diff line number Diff line change
Expand Up @@ -1352,6 +1352,7 @@ module.exports = {
'encyclopedia/workers/sticky-execution',
'encyclopedia/workers/worker-shutdown',
'encyclopedia/workers/worker-versioning',
'encyclopedia/workers/serverless-workers',
],
},
{
Expand Down
1 change: 1 addition & 0 deletions static/diagrams/serverless-worker-flow.svg
Loading
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
2 changes: 2 additions & 0 deletions vale/styles/Temporal/terms.yml
Original file line number Diff line number Diff line change
Expand Up @@ -102,6 +102,8 @@ swap:
temporal sdks: Temporal SDKs
temporal server: Temporal Server
'\bworker\b': Worker
serverless worker: Serverless Worker
serverless workers: Serverless Workers
worker controller: Worker Controller
'\bworkflow\b': Workflow
timer: Timer
Expand Down
Loading