ShopFlow Serverless Workers Demo

Feature: Temporal Serverless Workers (Pre-Release)
Vertical: E-Commerce / Retail
SDK: Go v1.42+
Compute: AWS Lambda

⚠️ PRE-RELEASE — In Dev
Serverless Workers is not yet available in production Temporal Cloud namespaces.
Pre-Release target: May 5, 2026 (Temporal Replay).
Run this demo against a local dev server or a dedicated demo namespace only.
Do NOT demo against a customer production account.

Pre-Demo Setup

1. Temporal Cloud - Staging: See if you have an account on the Staging portal - go here, try to log in with your temporal.io email address. If you get in, verify you have access to the sa-demo-01.temporal-dev namespace.
2. SA AWS Account: Instructions here on how to access the SA AWS account - you'll want read only access if you're running the demo with the infra as-is, and Admin access if you want to set up a new Lambda.
3. Obtain and save the cert information to connect to the namespace, and put the cert files in this folder - the temporal.toml file is otherwise all set up to connect to the correct Temporal Cloud and correct namespace.

Demo Script

This is the recommended live demo flow. It shows a workflow running on a local worker as well as the same workflow running on a serverless worker.

Step 1 — Start a workflow with the local worker (connected to Temporal Cloud)

In one terminal, start the local worker pointing at Temporal Cloud:

go run worker/main.go

In a second terminal, submit a workflow:

go run starter/main.go

You should see the workflow start and the local worker begin processing it.

Step 2 - Stop the locally running worker

Press Ctrl+C in the terminal running worker/main.go

Step 3 — Submit a second workflow and watch the Lambda worker pick it up

Run the starter again to submit a new workflow (or observe the in-flight one resume):

go run starter/main.go

The Lambda is located here if you use the one that's already set up! During the demo, show the Monitor tab - this will show the executions of the Lambda.

It may also be useful to show the workers associated with the shopflow-orders task queue, you can find that view here.

The Worker Control Plane automatically invokes the Lambda function. The workflow completes on the serverless worker — no local process needed.

The punchline: Temporal's durable execution model means work is never lost when a worker goes down. And with serverless workers, you don't need to keep any process running at all — Lambda is invoked on demand and scales to zero when idle.

---

What This Demonstrates

ShopFlow is a serverless order-fulfillment pipeline. An order workflow runs four activities (reserve inventory → charge customer → create shipment → notify customer) with automatic retry and saga-style compensation. The worker runs entirely on AWS Lambda — no long-lived processes, no Kubernetes, no scaling configuration. Temporal's Worker Control Plane invokes the Lambda function when there is work and lets it scale to zero when idle.

The "wow moment": After the workflow completes, open CloudWatch Metrics and show Lambda invocation count dropping to zero. Ask the customer: "How much are you spending on idle worker capacity today?"

---

Repository Layout

shopflow-serverless/
├── workflows/
│   └── order_workflow.go     # OrderWorkflow — deterministic orchestration
├── activities/
│   └── order_activities.go   # ReserveInventory, ChargeCustomer, CreateShipment, NotifyCustomer
├── lambda/
│   └── main.go               # AWS Lambda handler — uses lambdaworker.RunWorker (⭐ key API)
├── worker/
│   └── main.go               # Standard long-lived Temporal worker (local dev / K8s)
├── starter/
│   └── main.go               # Triggers a workflow execution (run locally)
├── temporal.toml             # Connection profiles (default = local, staging = Temporal Cloud)
├── go.mod
└── README.md

---

Prerequisites

Tool	Version	Notes
Go	1.24+	Required by sdk-go v1.42
AWS CLI	v2	Configured with appropriate credentials
zip	any	For Lambda deployment package

---

Connection Configuration

Both worker/main.go and starter/main.go load connection settings from temporal.toml via envconfig.LoadClientOptions. The file uses the staging profile, which targets Temporal Cloud Staging. The namespace connects via mTLS, so be sure to fill in the location of your certs in temporal.toml before running.

---

AWS Setup

Everything is already set up to run this workflow on a Lambda worker. If you need to change the worker, see below re: how to rebuild and redeploy. PLEASE NOTE - if you change this, you change it for everyone who may be using this demo.

1. Build the Go binary for Lambda

Lambda runs on Amazon Linux and is set up for x86_64. To build the (arm64 or x86_64). Cross-compile accordingly:

cd shopflow-serverless

# For x86_64, which is how the Lambda is set up:
GOOS=linux GOARCH=amd64 go build -o bootstrap ./lambda/

The binary must be named bootstrap for the provided.al2023 runtime.

2. Package and deploy

Environmental variables and certs are already set up for the Lambda in the SA AWS account!

zip function.zip bootstrap

On the Lambda page, upload the new ZIP and redeploy.

Lambda timeout guidance:
Set timeout to at least: max(activity StartToCloseTimeout) + 7s (worker stop timeout).
The activities in this demo have 2-minute timeouts, so a 5-minute (300s) Lambda timeout is appropriate. Minimum recommended: 60 seconds.

Updating the Lambda (Versioned Deployments)

TBD

---

Key SDK API Reference

// go.temporal.io/sdk/contrib/aws/lambdaworker

lambdaworker.RunWorker(
    worker.WorkerDeploymentVersion{
        DeploymentName: "my-service",  // logical name
        BuildID:        "v1.0.0",      // maps to Lambda version/ARN
    },
    func(opts *lambdaworker.Options) error {
        opts.TaskQueue = "my-queue"
        opts.RegisterWorkflow(MyWorkflow)
        opts.RegisterActivity(MyActivity)
        return nil
    },
)

RunWorker handles the full per-invocation lifecycle:

1. Dials Temporal Cloud using config from temporal.toml / env vars
2. Creates a worker with Lambda-tuned concurrency defaults
3. Polls for tasks until the invocation deadline approaches
4. Gracefully shuts down the worker and closes the client

Worker Deployment Versioning is always enabled — you do not need to configure it.

---

Pre-Release Limitations

• AWS Lambda only. GCP Cloud Run is planned for a future release.
• 15-minute Lambda hard limit. Activities with StartToCloseTimeout > 15 minutes require heartbeating + activity re-invocation patterns. The demo activities are well within limits.
• No production SLA. Do not use in customer production namespaces during pre-release.
• Configuration interface may change. The Worker Deployment UI/API is pre-release and subject to breaking changes before GA.
• Pricing TBD. No incremental charge is planned for the initial release.

---

Resources

• Temporal Go SDK lambdaworker package
• SDK Go v1.42 release notes
• Client environment configuration reference