docs: Serverless Workers - Evaluate pages (1/4) by lennessyy · Pull Request #4417 · temporalio/documentation

lennessyy · 2026-04-08T23:50:16Z

Summary

Adds the Evaluate section for Serverless Workers documentation, including the overview page and interactive demo page
Adds ServerlessWorkerDemo component and its CSS module
Adds sidebar entry under Features > Serverless Workers
Adds redirect from /evaluate/serverless-workers-demo to /evaluate/serverless-workers/demo
Changes onBrokenLinks and onBrokenAnchors from 'throw' to 'warn' to support incremental PRs with cross-references

This is PR 1 of 4, splitting #4405 into smaller PRs targeting feat/serverless-worker-prerelease.

Test plan

Verify the Evaluate > Features > Serverless Workers sidebar category renders correctly
Verify the overview page loads at /evaluate/serverless-workers
Verify the demo page loads at /evaluate/serverless-workers/demo
Verify the redirect from /evaluate/serverless-workers-demo works

🤖 Generated with Claude Code

┆Attachments: EDU-6189 docs: Serverless Workers - Evaluate pages (1/4)

Add the Evaluate section for Serverless Workers documentation: - Serverless Workers overview page - Interactive demo page with ServerlessWorkerDemo component - Sidebar entry under Features - Redirect from old demo URL - Change onBrokenLinks/onBrokenAnchors to 'warn' for incremental PRs Part 1 of 4, splitting PR #4405 into smaller PRs. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>

vercel · 2026-04-08T23:50:23Z

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated (UTC)
temporal-documentation	Ready	Preview, Comment	Apr 16, 2026 10:48pm

github-actions · 2026-04-08T23:51:01Z

📖 Docs PR preview links

Evaluate
- Serverless Workers
  - Interactive Demo

bchav · 2026-04-09T17:44:42Z

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


The workers, while alive, still poll the server.

bchav · 2026-04-09T17:44:57Z

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


We do not handle provisioning (yet).

bchav · 2026-04-09T17:45:55Z

+### 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.


Customers still need to manage deployments. We simplify the deployment process (because of the simplicity of serverless providers), reduce the ongoing infrastructure management burden, handle autoscaling, scale to zero.

bchav · 2026-04-09T17:47:35Z

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


If the work flows are long running, it's a good fit. If you have an activity that needs longer than 15 minutes and cannot be interrupted, lambda is not a good fit. This limitation does not apply to cloud run.

bchav · 2026-04-09T17:48:00Z

+
+- **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.


@smuneebahmad Is this true? Should we comment on how sticky works here?

This is here primarily because in Go it looks like DisableEagerActivities is set to always true (users can't override). But yeah if there is a roadmap to remove these limitations we can remove this bullet

We can either remove this bullet point, or say:

**You need long running persistent connections**. Some features require a long running persistent connection between the Worker and Temporal, beyond the maximum runtime duration of a serverless worker like AWS Lambda.

I'd love to be specific here if possible. Can we name specific features that require a persistent connection?

I wouldn't want to remove this if the limitation is real and unlikely to change. This page is not meant to be push users to serverless. We want to be helpful here to help them choose serverless vs stick with traditional workers.

- Fix polling description: serverless workers still poll, the difference is lifecycle - Tone down operational overhead claims: customers still deploy and configure - Clarify long-running limitation applies to activities, not workflows Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>

akhayam · 2026-04-12T03:54:12Z

+
+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 running a long-lived process, Temporal triggers the compute environment when Tasks arrive, the Worker starts and polls for available Tasks, and then exits when the work is done.


...Temporal triggers the compute environment when Tasks arrive...
Recommend using Lambda's nomenclature here: "...Temporal invokes a serverless function when Tasks arrive..."

akhayam · 2026-04-12T03:57:13Z

+
+Serverless Workers may not be ideal when:
+
+- **Activities are long-running and cannot be interrupted.** Serverless platforms enforce execution time limits (for example, AWS Lambda has a 15-minute maximum). Activities that run longer than the provider's timeout and cannot be broken into smaller steps need a different hosting strategy. Long-running Workflows are not affected because Workflows can span multiple invocations.


for example, AWS Lambda has a 15-minute maximum
for example, AWS Lambda has a 15-minute execution limit

akhayam · 2026-04-12T03:59:59Z

+| **Lifecycle** | Long-lived process that runs continuously. | Invoked on demand. Starts and stops per invocation. |
+| **Scaling** | You manage scaling (Kubernetes HPA, instance count, etc.). | Temporal invokes additional instances as needed, within the compute provider's concurrency limits. |
+| **Connection** | Persistent connection to Temporal. | Fresh connection on each invocation. |
+| **Worker Versioning** | Optional but recommended. | Required. |


I don't think "Worker Versioning --> Required" is true.

AWS allows Unqualified Lambdas and that's what we are using for pre-release.

@bchav Do we not need worker versioning? I thought with serverless you had to have a worker deployment version

Just to clarify my nuance: The workers themselves need to be versioned because we need to create Worker Deployment (WD) and then Worker Deployment Version (WDV) in the Compute Config. But the way it's written in the table, it looks like unversioned / unqualified Lambdas won't work.

I see. I will revise the wording here to make that clear.

On second thought will just remove this row as it's a lower level detail than should be in this page

smuneebahmad · 2026-04-16T21:15:16Z

+                value={config.lambdaFunctionName}
+                onChange={handleFunctionNameChange}
+              />
+              <ConfigField


We don't need to specify Min and Max instances for serverless functions like AWS Lambda. These settings are more suited for replica-based compute providers like AWS ECS or Google Cloud Run

smuneebahmad · 2026-04-16T21:18:12Z

+  --deployment-name ${deploymentName} \\
+  --build-id ${buildId} \\
+  --aws-lambda-invoke ${lambdaArn} \\
+  --scaler-min-instances ${scalerMin} \\


We can remove --scaler-min-instances and --scaler-max-instances for AWS Lambda example

smuneebahmad · 2026-04-16T21:18:54Z

+  --namespace ${namespace} \\
+  --deployment-name ${deploymentName} \\
+  --build-id ${buildId} \\
+  --ignore-missing-task-queues`;


We don't need to specify --ignore-missing-task-queues

smuneebahmad · 2026-04-16T21:23:14Z

+
+- **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.


We can either remove this bullet point, or say:

**You need long running persistent connections**. Some features require a long running persistent connection between the Worker and Temporal, beyond the maximum runtime duration of a serverless worker like AWS Lambda.

- Reframe lifecycle description: Temporal invokes the Serverless Worker on demand (bchav, akhayam) - Clarify operational overhead: offload invocation and scaling, but deployments remain the user's responsibility (bchav) - Introduce "long-lived Workers" terminology and use consistently - Sharpen Lambda execution limit wording and Cloud Run callout (akhayam, bchav) - Remove Worker Versioning row from comparison table as too low-level (akhayam) - Remove --scaler-min-instances, --scaler-max-instances, and --ignore-missing-task-queues from demo CLI snippets (smuneebahmad) - Remove Min/Max Instances config fields from demo UI (smuneebahmad) Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

lennessyy requested a review from a team as a code owner April 8, 2026 23:50

vercel bot deployed to Preview April 8, 2026 23:51 View deployment

sync-by-unito bot assigned lennessyy Apr 9, 2026

bchav reviewed Apr 9, 2026

View reviewed changes

vercel bot deployed to Preview April 9, 2026 22:12 View deployment

akhayam reviewed Apr 12, 2026

View reviewed changes

smuneebahmad reviewed Apr 16, 2026

View reviewed changes

vercel bot deployed to Preview April 16, 2026 22:48 View deployment

lennessyy merged commit 18f8d0e into feat/serverless-worker-prerelease Apr 16, 2026
10 checks passed

lennessyy deleted the feat/serverless-worker-1-evaluate branch April 16, 2026 23:38


		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.


		Serverless Workers may not be ideal when:

		- Activities are long-running and cannot be interrupted. Serverless platforms enforce execution time limits (for example, AWS Lambda has a 15-minute maximum). Activities that run longer than the provider's timeout and cannot be broken into smaller steps need a different hosting strategy. Long-running Workflows are not affected because Workflows can span multiple invocations.

Conversation

lennessyy commented Apr 8, 2026 • edited by sync-by-unito bot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Summary

Test plan

Uh oh!

vercel bot commented Apr 8, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

github-actions bot commented Apr 8, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

📖 Docs PR preview links

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

bchav Apr 9, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

lennessyy Apr 16, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

akhayam Apr 13, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

lennessyy commented Apr 8, 2026 •

edited by sync-by-unito bot

Loading

vercel bot commented Apr 8, 2026 •

edited

Loading

github-actions bot commented Apr 8, 2026 •

edited

Loading

bchav Apr 9, 2026 •

edited

Loading

lennessyy Apr 16, 2026 •

edited

Loading

akhayam Apr 13, 2026 •

edited

Loading