docs: Serverless Workers - Evaluate pages (1/4)#4417
docs: Serverless Workers - Evaluate pages (1/4)#4417lennessyy wants to merge 1 commit intofeat/serverless-worker-prereleasefrom
Conversation
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>
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
📖 Docs PR preview links
|
|
|
||
| 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. |
There was a problem hiding this comment.
The workers, while alive, still poll the server.
|
|
||
| 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. |
There was a problem hiding this comment.
We do not handle provisioning (yet).
| ### 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. |
There was a problem hiding this comment.
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.
|
|
||
| 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. |
There was a problem hiding this comment.
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.
|
|
||
| - **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. |
There was a problem hiding this comment.
@smuneebahmad Is this true? Should we comment on how sticky works here?
There was a problem hiding this comment.
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
2 participants
Summary
ServerlessWorkerDemocomponent and its CSS module/evaluate/serverless-workers-demoto/evaluate/serverless-workers/demoonBrokenLinksandonBrokenAnchorsfrom'throw'to'warn'to support incremental PRs with cross-referencesThis is PR 1 of 4, splitting #4405 into smaller PRs targeting
feat/serverless-worker-prerelease.Test plan
/evaluate/serverless-workers/evaluate/serverless-workers/demo/evaluate/serverless-workers-demoworks🤖 Generated with Claude Code
┆Attachments: EDU-6189 docs: Serverless Workers - Evaluate pages (1/4)