# Serverless Workers

> For the complete documentation index, see [llms.txt](https://docs.temporal.io/llms.txt).
> Any documentation page is available as raw Markdown by appending `.md` to its URL.

> **Public Preview**
> AWS Lambda support is in Public Preview. Support for GCP Cloud Run and Amazon Bedrock AgentCore Runtime is in
> Pre-release. To request access to Pre-release compute providers on Temporal Cloud, create a
> [support ticket](/evaluate/cloud/support#support-ticket) or contact your account team. You can also
> [sign up for updates](https://temporal.io/pages/serverless-workers-updates) or try them through self-hosting.

Serverless Workers let you run Temporal Workers on AWS Lambda, Amazon Bedrock AgentCore Runtime, and GCP Cloud Run.
There are no servers to provision, no Worker fleet to scale, and no idle Worker fleet to maintain. Temporal starts
Worker capacity when Tasks arrive and scales it down when the work drains.

Serverless Workers use the same Temporal SDKs as traditional long-lived Workers. You register Workflows and Activities
the same way. The difference is in the lifecycle: Temporal manages it instead of you running a Worker process. How that
lifecycle works depends on the provider. On AWS Lambda, Temporal invokes a function per unit of work, and the Worker
exits when the invocation ends. On AgentCore Runtime, Temporal invokes Runtime sessions that host standard long-running
Workers. On GCP Cloud Run, Temporal resizes a pool of long-lived instances, scaling it to zero when there is no work.

For a deeper look at how Serverless invocation works under the hood, see [Serverless Workers](/serverless-workers) in
the encyclopedia.

> **💡 Tip:**
> Use the Serverless Workers Skill
>
> The [Temporal Serverless Workers Skill](https://github.com/temporalio/skill-temporal-serverless) gives your AI coding
> agent the knowledge to write, package, deploy, and troubleshoot Serverless Workers. See
> [Develop with AI](/with-ai#skills) for installation instructions.
>

## Why use Serverless Workers?

Serverless Workers are a good fit for many workloads. They offer several advantages compared to long-lived Workers on
dedicated compute.

### Reduce operational overhead

Long-lived Workers require you to provision infrastructure, configure scaling policies, manage deployments, and monitor
host-level health. Serverless Workers reduce this burden by offloading invocation and scaling to Temporal and the
compute provider. You still deploy the Worker package and configure the compute provider, but there is no always-on
infrastructure to manage and no autoscaling policies to tune.

Worker management is one of the most common sources of support questions for Temporal users. Serverless Workers offer a
prescriptive deployment path that reduces the operational surface area and lets you focus on writing Workflows instead
of managing infrastructure.

### Get started faster

Running a long-lived Worker requires choosing a hosting strategy, configuring compute resources, and setting up
deployment pipelines before you can execute your first Workflow in production.

With Serverless Workers, you package your Worker code, deploy it to your serverless provider, and configure the
connection to Temporal. There is no need to set up Kubernetes, manage container orchestration, or design a scaling
strategy.

### Scale automatically

Temporal scales the compute for you. When Task volume increases, it asks the provider for more capacity. When traffic
drops, it scales back down. When there is no work, there is no compute running.

This automatic scaling is especially useful for bursty, event-driven workloads where traffic patterns are unpredictable
or highly variable.

### Pay only for what you use

Long-lived Workers run continuously, whether or not there is work to process. Serverless Workers run only when Tasks are
available, so you pay for compute while work is in flight rather than around the clock. For workloads with low or
intermittent volume, that can cut compute costs.

## When to use Serverless Workers

Serverless Workers are a good fit when:

- **Workloads are bursty or event-driven.** Order processing, notifications, webhook handlers, and similar workloads
  that experience spiky traffic benefit from automatic scaling without over-provisioning.
- **Traffic is low or intermittent.** If Workers spend most of their time idle, Serverless Workers eliminate the cost of
  always-on compute.
- **You want a simpler getting-started path.** Deploying a function is simpler than setting up a container orchestration
  platform. Serverless Workers reduce the steps between writing Worker code and running your first Workflow.
- **Your organization has standardized on serverless.** Teams that already run services on Lambda, AgentCore Runtime,
  Cloud Run, or similar platforms can run Temporal Workers using the same deployment patterns and tooling.
- **You serve multiple tenants with infrequent workloads.** Platforms that run Workflows on behalf of many users or
  customers can avoid running dedicated Workers per tenant.

Serverless Workers may not be ideal when:

- **Activities are long-running and cannot be interrupted.** Some serverless platforms enforce execution time limits.
  For example, AWS Lambda has a 15-minute execution limit. Activities that run longer than the provider's timeout and
  cannot be broken into smaller steps need a different hosting strategy or a provider with a longer compute lifetime.
  AgentCore Runtime sessions can provide up to 8 hours of uninterrupted compute. Long-running Workflows are not
  affected because Temporal maintains their state and execution progress across Worker processes.
- **Workloads require sustained high throughput.** For consistently high-volume Task Queues, long-lived Workers on
  dedicated compute may be more cost-effective and performant.
- **You need a persistent connection to Temporal.** Some features require the Worker to hold a connection open. On AWS
  Lambda each invocation connects fresh, so those features do not apply. AgentCore Runtime Workers and Cloud Run
  instances hold a connection for the lifetime of their compute.

## How Serverless Workers compare to long-lived Workers

|                | Long-lived Worker                                          | Serverless Worker                                                                                  |
| -------------- | ---------------------------------------------------------- | -------------------------------------------------------------------------------------------------- |
| **Lifecycle**  | Long-lived process that runs continuously.                 | Temporal starts and stops it according to the compute provider's lifecycle.                         |
| **Scaling**    | You manage scaling (Kubernetes HPA, instance count, etc.). | Temporal adds capacity as needed, within the compute provider's limits.                            |
| **Connection** | Persistent connection to Temporal.                         | Fresh per Lambda invocation. Held for the compute lifetime on AgentCore Runtime and Cloud Run.     |

## Supported providers

All three providers can serve long-running Workflows because Workflow lifetime is independent of Worker lifetime. The
provider's compute limit applies to an individual Worker invocation or compute instance, not to the total Workflow
duration.

| Provider | Worker lifecycle | Consider this provider when |
| --- | --- | --- |
| [AWS Lambda](/serverless-workers/aws-lambda) | Temporal invokes a function per unit of work. Each invocation can run for up to 15 minutes. | You want general-purpose, event-driven AWS compute, and individual Activity attempts fit within the Lambda invocation window. |
| [Amazon Bedrock AgentCore Runtime](/serverless-workers/agentcore) | Temporal invokes Runtime sessions that host standard long-running Workers. Each session can provide up to 8 hours of uninterrupted compute. | You are building agents on AWS, want to use AgentCore services, need longer Activity attempts, or benefit from process-local reuse while the Runtime compute remains available. |
| [GCP Cloud Run](/serverless-workers/cloud-run) | Temporal adjusts the size of a Worker Pool of long-lived instances. | You want a managed pool of container-based Workers on Google Cloud. |

## Next steps

- [Interactive demo](/demos/serverless-workers) to explore the configuration and invocation flow.
- [How Serverless Workers work](/serverless-workers) for a deeper look at the invocation lifecycle, compute providers,
  and architecture.
- [Test a Serverless Worker locally with LocalStack](/production-deployment/worker-deployments/serverless-workers/aws-lambda/local-development)
  to run the full AWS Lambda invocation loop on your machine with no AWS account.
- [Deploy a Serverless Worker](/production-deployment/worker-deployments/serverless-workers) for the end-to-end
  deployment guide.

For the Worker code itself, pick your SDK and provider:

| SDK | AWS Lambda | Amazon Bedrock AgentCore Runtime | GCP Cloud Run |
| --- | --- | --- | --- |
| Go | [Lambda Workers in Go](/develop/go/workers/serverless-workers/aws-lambda) |  | [Cloud Run Workers in Go](/develop/go/workers/serverless-workers/cloud-run) |
| Python | [Lambda Workers in Python](/develop/python/workers/serverless-workers/aws-lambda) | [AgentCore Runtime Workers in Python](/develop/python/workers/serverless-workers/agentcore) | [Cloud Run Workers in Python](/develop/python/workers/serverless-workers/cloud-run) |
| TypeScript | [Lambda Workers in TypeScript](/develop/typescript/workers/serverless-workers/aws-lambda) |  | [Cloud Run Workers in TypeScript](/develop/typescript/workers/serverless-workers/cloud-run) |
| Java | [Lambda Workers in Java](/develop/java/workers/serverless-workers/aws-lambda) |  | [Cloud Run Workers in Java](/develop/java/workers/serverless-workers/cloud-run) |
| .NET | [Lambda Workers in .NET](/develop/dotnet/workers/serverless-workers/aws-lambda) |  | [Cloud Run Workers in .NET](/develop/dotnet/workers/serverless-workers/cloud-run) |
| Ruby |  |  | [Cloud Run Workers in Ruby](/develop/ruby/workers/serverless-workers/cloud-run) |
| Rust |  |  | [Cloud Run Workers in Rust](/develop/rust/workers/serverless-workers/cloud-run) |