Conversation
- Go SDK page: lambdaworker package usage, config, lifecycle - Deployment guide: end-to-end Lambda setup (provider-agnostic) - Interactive demo component for the Evaluate section - Sidebar entries for all three pages Updated deployment guide based on dogfooding against local server with temporal-auto-scaled-workers. Removed Cloud-specific language so the guide works for both Cloud and self-hosted deployments. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
📖 Docs PR preview links
|
…o/documentation into feat/serverless-worker
Point Go WorkerOptions links to pkg.go.dev reference instead of removed anchors on the simplified run-worker-process page. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Add deploy guide for serverless workers covering AWS Lambda deployment, including the serverless-workers index and aws-lambda pages under production-deployment/worker-deployments. Update sidebar navigation and set onBrokenLinks/onBrokenAnchors to warn for cross-PR references. Part of #4405. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Add Go SDK Serverless Workers documentation including the lambdaworker package guide for AWS Lambda, rewrite run-worker-process to focus on long-lived Workers, and remove cloud-worker (content folded in). Update sidebars, add redirect, and set broken links to warn for cross-PR references. Part of #4405. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
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>
| ## Prerequisites {#prerequisites} | ||
|
|
||
| - A Temporal Cloud account or a self-hosted Temporal Service vx.xx.x or later. | ||
| - Your Temporal Service frontend must be reachable from the Lambda execution environment. For Temporal Cloud, no additional configuration is needed. For self-hosted deployments on a private network, configure the Lambda function with [VPC access](https://docs.aws.amazon.com/lambda/latest/dg/configuration-vpc.html) to reach the Temporal frontend. |
There was a problem hiding this comment.
Right now, I see that we need to add specific dynamic config parameters in Temporal server to enable this feature. When we ship, do self-hosted or cloud users need to do anything to enable it?
In the same vein, the WCI component readme mentions a scaling algorithm. Is this something users need to worry about? If so, what are the considerations? If not, can we still give a brief explanation of how it works and expected scaling behavior?
| | `LambdaFunctionArn` | The ARN of the Lambda function that Temporal will invoke. | | ||
|
|
||
| <!-- | ||
| TODO: Add the CloudFormation template once it's finalized. |
There was a problem hiding this comment.
In the UX design discussions we mentioned helping users create the roles using cloud formation templates. I haven't seen the template--is this still the plan?
| @@ -41,7 +41,7 @@ A Worker Program is the static code that defines the constraints of the Worker P | |||
| - [How to run a development Worker using the TypeScript SDK](/develop/typescript/workers/run-worker-process#run-a-dev-worker) | |||
There was a problem hiding this comment.
The worker page is going to need a rewrite. With serverless workers, I think we need to update how users should think of this abstraction that we never quite defined well in the docs. Would love some product/engineering input on this question.
- What is a worker?
We don't answer this question at all right now, and deflect to lower-level abstractions, which isn't very helpful and does not account for serverless workers:
In day-to-day conversations, the term Worker is used to denote either a Worker Program, a Worker Process, or a Worker Entity. Temporal documentation aims to be explicit and differentiate between them.
Maybe something like:
A Worker is the execution environment for your Workflows and Activities. It's where your application code actually runs within Temporal's architecture.
I want to
The comparison table lives on the evaluate page now. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
…K page Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
…ineBuffer is serverless-only Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Summary
Documentation for Serverless Workers across four sections:
evaluate/development-production-features/serverless-workers/) — Benefits, use cases, comparison table, and interactive demo. The "should I use this?" page.encyclopedia/workers/serverless-workers.mdx) — How invocation works (6-step flow with diagram), compute providers, WCI. Language-agnostic concepts.production-deployment/worker-deployments/serverless-workers/) — Step-by-step: write code, deploy Lambda, configure IAM, create version, set current, verify. Uses SDK tabs (Go only for now).develop/go/workers/serverless-workers/) —lambdaworkerpackage usage, connection config, Lambda-tuned defaults, OpenTelemetry.Also: simplified
run-worker-process.mdx, deletedcloud-worker.mdx(redirected), updated interactive demo to match deploy guide, added "Serverless Worker" to Vale terms.Preview links
Evaluate
Encyclopedia
Deploy guide
Go SDK
Go SDK (refactored)
Test plan
/develop/go/workers/cloud-workerand/evaluate/serverless-workers-demo🤖 Generated with Claude Code