Introducing Temporal Serverless Workers: Deploy Temporal Workers to AWS Lambda

Temporal Workers are the backbone of every Temporal application. They’re the processes that execute your Workflows and Activities.

Today we’re announcing Temporal Serverless Workers in both Temporal Cloud and self-hosted Temporal. Serverless Workers introduce two new capabilities:

• You can now deploy your Temporal Worker code directly to serverless compute platforms, starting with AWS Lambda.
• Temporal now automatically invokes, scales, and gracefully shuts down (scaling to zero, if appropriate) Temporal Workers on your behalf based on workload volume and metrics.

Serverless Workers reduce Time to First Workflow by removing infrastructure planning overhead and eliminating the need for autoscaling strategy design. They also simplify ongoing Worker lifecycle and operational management: write your Workflow and Activity code the same way you do today, deploy your Worker to Lambda, and tell Temporal about the Lambda function. From there, Temporal takes over creating the right number of Workers to process your workload.

This feature is available in Pre-release and supports Serverless Workers on AWS Lambda using the Go, Python, and TypeScript SDKs. We will soon expand support to additional SDKs, as well as Google Cloud Run.

Sign up for Pre-release access →

Why Serverless Workers?#

• Reduce Time to First Workflow. No decisions around container orchestration, no scaling strategy to design up front. Deploying a Worker is as simple as deploying a function.
• Scale out, and to zero, automatically. Serverless platforms offer scaling natively, and the Temporal autoscaling algorithm for Serverless Workers triggers new invocations when there is work to do. This is especially valuable for bursty, event-driven workloads with unpredictable traffic patterns, such as order processing, AI agents, and notification pipelines.
• Reduce operational overhead. No servers to provision, no autoscaling policies to configure, no clusters to monitor, no Workers that require periodic software upgrades. Worker infrastructure management is one of the most common sources of support questions from Temporal users, and Serverless Workers offer a prescriptive deployment path that dramatically reduces that surface area.
• Pay only for what you use. With a traditional, self-managed Worker, you pay for compute whether or not there’s work to do. With Serverless Workers, you pay per invocation. For low-volume or intermittent workloads, this can mean significant cost savings.

How it works#

The programming model for Serverless Workers is the same as self-managed Workers. Write Workflows and Activities using the Temporal SDK and register them on a Worker, just like you do today. From there, there are just three steps to setting up your Worker:

1. Upload your Worker code to AWS Lambda.
2. Create the cross-account IAM role for invocation of the Lambda function by using the Temporal-provided CloudFormation template.
3. Tell Temporal about the Lambda function using the CLI or the UI.

The difference with Serverless Workers is in the lifecycle. With a traditional, self-managed Worker, you start a long-lived process that continuously polls a Task Queue. With Serverless Workers, when Tasks arrive on a Task Queue, Temporal invokes functions running in your AWS account directly. No long-running processes, no idle compute, and no infrastructure to manage. When the work is done, the Worker shuts down, scaling down to zero if appropriate. The end-to-end execution flow:

1. A Task arrives on a Task Queue that has a serverless compute provider configured.
2. Temporal detects whether a Worker is actively polling the queue, evaluates Task Queue metrics (approximate backlog count, sync match rate), and decides if a new Worker should be invoked.
3. Temporal assumes an IAM role in your AWS account and invokes the Lambda function.
4. The Lambda function starts a Worker, which polls the Task Queue, processes available Tasks, and gracefully shuts down before the Lambda deadline.

Each invocation is a fresh connection to Temporal. This is what makes it serverless: you don’t manage the process lifecycle; Temporal and your cloud provider do.

One important note: long-running Workflows work perfectly with Serverless Workers because Workflows naturally span multiple Worker invocations. The constraint is on individual Activity execution time, which is bounded by Lambda’s invocation limits (maximum 15 minutes).

The developer experience#

Here’s what a Serverless Worker looks like in Go. The lambdaworker package provides a single entry point, RunWorker, which handles the Lambda lifecycle, Temporal client setup, and graceful shutdown:

package main

import (
    "go.temporal.io/sdk/contrib/aws/lambdaworker"
    "go.temporal.io/sdk/worker"
    "go.temporal.io/sdk/workflow"
)

func main() {
    lambdaworker.RunWorker(worker.WorkerDeploymentVersion{
        DeploymentName: "my-app",
        BuildID:        "build-1",
    }, func(opts *lambdaworker.Options) error {
        opts.TaskQueue = "my-task-queue"
        opts.RegisterWorkflowWithOptions(MyWorkflow, workflow.RegisterOptions{
            VersioningBehavior: workflow.VersioningBehaviorAutoUpgrade,
        })
        opts.RegisterActivity(MyActivity)
        return nil
    })
}

A few things to notice: you provide a WorkerDeploymentVersion with a deployment name and build ID. The registration API is the same RegisterWorkflow and RegisterActivity you already know.

Once your function is deployed to Lambda, you tell Temporal about it by creating a Worker Deployment Version with the Lambda ARN and scaling configuration:

temporal worker deployment create-version \
  --deployment-name my-app --build-id build-1 \
  --aws-lambda-invoke arn:aws:lambda:us-east-1:123456789:function:my-temporal-worker \
  --scaler-min-instances 0 --scaler-max-instances 5

That’s it. From here, any Workflow started on your Task Queue will trigger Lambda invocations automatically. The full deploy guide, which includes IAM configuration and step-by-step instructions, is in the Serverless Workers documentation.

When to use Serverless Workers#

Serverless Workers are a great fit for:

• Bursty or event-driven workloads. Order processing, notifications, and webhook handlers where traffic is unpredictable.
• Low or intermittent volume. Eliminate the cost of idle compute when work only arrives periodically.
• Serverless-native organizations. If your organization has standardized on Lambda, your Workers can live alongside the rest of your infrastructure.
• Getting started quickly. Skip the infrastructure decisions and go straight to deploying your business logic.

Self-managed Workers are still a good choice for sustained high-throughput workloads where dedicated compute is more cost-effective, or for Activities that require long, uninterrupted execution. Think of it as two deployment models: maximum flexibility with traditional Workers, maximum simplicity with Serverless Workers.

What’s next#

This Pre-release launches with AWS Lambda and the Go, Python, and TypeScript SDKs. We’re actively working on:

• Additional compute providers, bringing the same serverless deployment model to more cloud platforms, with Google Cloud Run coming soon.
• Additional SDK support, beyond the Go, Python, and TypeScript SDKs available today.

Get started#

Sign up for Pre-release access →

• Evaluate Serverless Workers: understand use cases and see the interactive demo.
• Go SDK guide: the lambdaworker package API and configuration reference.
• Deploy guide: end-to-end instructions from code to running Workflow.
• How Serverless Workers work: deep dive into the invocation model and architecture.

We’d love your feedback as we shape this feature. Reach out through your Temporal support channel or join the conversation in the Temporal Community Slack.