Serverless Workers
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 in the encyclopedia.
The Temporal Serverless Workers Skill gives your AI coding agent the knowledge to write, package, deploy, and troubleshoot Serverless Workers. See Develop with AI 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 | 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 | 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 | 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 to explore the configuration and invocation flow.
- How Serverless Workers work for a deeper look at the invocation lifecycle, compute providers, and architecture.
- Test a Serverless Worker locally with LocalStack to run the full AWS Lambda invocation loop on your machine with no AWS account.
- Deploy a Serverless Worker 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 | Cloud Run Workers in Go | |
| Python | Lambda Workers in Python | AgentCore Runtime Workers in Python | Cloud Run Workers in Python |
| TypeScript | Lambda Workers in TypeScript | Cloud Run Workers in TypeScript | |
| Java | Lambda Workers in Java | Cloud Run Workers in Java | |
| .NET | Lambda Workers in .NET | Cloud Run Workers in .NET | |
| Ruby | Cloud Run Workers in Ruby | ||
| Rust | Cloud Run Workers in Rust |