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.

Temporal Serverless Workers makes it possible to run Temporal Workers on Serverless platforms, such as AWS Lambda, removing the need to perform infrastructure planning and develop your own autoscaling strategy just to get started with Temporal. Serverless Workers are the fastest way to launch your first workflow on Temporal; to learn more, see here:

Today we’re graduating Serverless Workers for AWS Lambda from a pre-release feature to Public Preview, meaning it’s available to anyone using Temporal Cloud. Temporal supports Serverless Workers on AWS Lambda using the Go, Python, Java, .Net, and TypeScript SDKs.

During our pre-release, we’ve had many customers kick the tires, run scale tests, and even go against our best practice recommendations to use it in production (and successfully, we might add!) In our webinar on Serverless Workers, we demonstrated the scaling capabilities of Temporal Workers running on AWS Lambda, scaling from 0-4000 Workers and processing 100,00 Workflows in under an hour, all for around $10 of Lambda compute costs (at list price!):

But you don’t have to take our word for it! Get started with Serverless Workers today.

Why Serverless Workers?#

With Serverless Workers for AWS Lambda, Temporal allows you to deploy Workers directly on serverless platforms and removes the barrier of infrastructure planning just to get started with Temporal. Some of the benefits you’ll gain from this are as follows:

• 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.

Deploy your Workers on Serverless today#

• Read our deployment guide for how to deploy your first Serverless Workers
• Read the Serverless Workers concept docs for the full technical overview and to understand how things work under the hood
• Try it yourself and see how it all works with our interactive demo
• If you need help troubleshooting, read our Troubleshooting Guide or reach out to our team for help
• New to Temporal Cloud? Sign up and get $1,000 in free credits to try it out.