# Serverless Workers

> **Pre-release**
> To request access during Pre-release, create a [support ticket](/cloud/support#support-ticket) or contact your account team.
> APIs are experimental and may be subject to backwards-incompatible changes.
> [Sign up for updates](https://temporal.io/pages/serverless-workers-updates) to be notified when Serverless Workers reach Public Preview.

Serverless Workers let you run Temporal Workers on serverless compute platforms like AWS Lambda and GCP Cloud Run. There
are no servers to provision, no clusters to scale, and no idle compute to pay for. Temporal starts Workers when Tasks
arrive and stops them 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 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.

## 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 function 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, deploying a Worker is as simple as deploying a function. 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, 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 longer limits (such as Cloud
  Run). Long-running Workflows are not affected because Workflows can span multiple invocations.
- **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. Cloud Run instances are long-lived and hold a
  connection for as long as the instance runs.

## 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: per invocation on AWS Lambda, by pool size on GCP Cloud Run.          |
| **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 connection per invocation on AWS Lambda. Held for the instance's lifetime on GCP Cloud Run.  |

## Supported providers

| Provider      | Compute                                                                     |
| ------------- | --------------------------------------------------------------------------- |
| AWS Lambda    | A function Temporal invokes per unit of work.                                |
| GCP Cloud Run | A Worker Pool of long-lived instances whose size Temporal scales.            |

## 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.
- [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 | 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) | [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) |