Serverless Workers
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 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 to explore the configuration and invocation flow.
- How Serverless Workers work for a deeper look at the invocation lifecycle, compute providers, and architecture.
- Deploy a Serverless Worker 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 | Cloud Run Workers in Go |
| Python | Lambda Workers in Python | Cloud Run Workers in Python |
| TypeScript | Lambda Workers in TypeScript | Cloud Run Workers in TypeScript |