Skip to main content

Serverless Workers

Serverless Workers let you run Temporal Workers on serverless compute platforms like AWS Lambda. There are no servers to provision, no clusters to scale, and no idle compute to pay for. Temporal invokes the Worker when Tasks arrive, and the Worker shuts down when the work is done.

Serverless Workers use the same Temporal SDKs as traditional Workers. You register Workflows and Activities the same way. The difference is in the lifecycle: instead of a long-lived process that polls continuously, Temporal triggers the compute environment on demand, the Worker processes available Tasks, and then exits.

For a deeper look at how Serverless invocation works under the hood, see Serverless Workers in the encyclopedia.

Benefits​

Reduce operational overhead​

Traditional Workers require you to provision infrastructure, configure scaling policies, manage deployments, and monitor host-level health. Serverless Workers remove this burden. The compute provider handles provisioning, scaling, and infrastructure management.

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 traditional Worker requires choosing a hosting strategy, configuring compute resources, and setting up deployment pipelines before you can execute your first Workflow.

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​

Serverless compute providers handle scaling natively. When Task volume increases, the provider spins up additional function instances. When traffic drops, instances scale 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​

Traditional Workers run continuously, whether or not there is work to process. Serverless Workers run only when Tasks are available. For workloads with low or intermittent volume, this pay-per-invocation model can significantly reduce 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:

  • Workloads are long-running. Serverless platforms enforce execution time limits (for example, AWS Lambda has a 15-minute maximum). Activities that run longer than the provider's timeout need a different hosting strategy.
  • 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 persistent connections. Some features require a persistent connection between the Worker and Temporal, which serverless invocations do not maintain.

How Serverless Workers compare to traditional Workers​

Traditional WorkerServerless Worker
LifecycleLong-lived process that runs continuously.Invoked on demand. Starts and stops per invocation.
ScalingYou manage scaling (Kubernetes HPA, instance count, etc.).Temporal invokes additional instances as needed, within the compute provider's concurrency limits.
ConnectionPersistent connection to Temporal.Fresh connection on each invocation.
Worker VersioningOptional but recommended.Required.

Supported providers​

ProviderStatus
AWS LambdaAvailable

Next steps​