By Temporal just removed the one thing that kept most developers away from it. At Replay 2026 in San Francisco, the company shipped Serverless Workers: run your Temporal Workers on AWS Lambda, and Temporal handles invocation, scaling, and shutdown for you. No servers to provision. No autoscaling policies to configure. No idle compute eating your bill at 3 AM. It is in pre-release today, and if you have been deferring Temporal because of the operational overhead, that excuse is gone.
Serverless Workers: What Actually Changed
The traditional Temporal Worker is a long-lived process that continuously polls a Task Queue. You manage it: provision the machine, configure autoscaling, handle graceful shutdowns, and pay for idle compute between traffic spikes. For teams already operating on serverless infrastructure, this was a hard sell.
Serverless Workers flip the model. When a task arrives on a Task Queue with no active Worker polling, Temporal evaluates queue backlog metrics and invokes your AWS Lambda function directly — using an IAM role in your own AWS account. The Lambda starts a Worker, processes available tasks, and shuts down gracefully before the Lambda timeout. No long-running process. No infrastructure to manage.
The programming model is identical. You register Workflows and Activities the same way you always have:
worker = Worker(
client,
task_queue="my-task-queue",
workflows=[MyWorkflow],
activities=[my_activity],
)
Deploy that as a Lambda function. Temporal handles invocation timing based on Task Queue backlog metrics. Currently in pre-release for Go, Python, and TypeScript SDKs, with Java, .NET, and Google Cloud Run support on the way. The one real constraint: individual Activity execution is bounded by Lambda’s 15-minute limit. Long-running Workflows span multiple invocations naturally, so that is not an issue in practice.
Standalone Activities: Durable Jobs Without a Workflow
The second announcement from Replay 2026 deserves more attention than it is getting. Standalone Activities let you run a single Activity as an independent durable job — no Workflow required.
Previously, getting Temporal’s durability guarantees meant writing a Workflow wrapper around every background task. That overhead pushed teams toward Redis+Celery or SQS patterns instead. Standalone Activities close that gap:
handle = await client.start_activity(
send_email,
args=[user_id, "welcome"],
task_queue="jobs",
schedule_to_close_timeout=timedelta(hours=1),
)
Submit it, and Temporal persists the job to durable storage before acknowledging the request. If your Worker crashes mid-execution, the job retries automatically. It appears in the Temporal Web UI for visibility. The same Activity code works as a Standalone Activity or as a step inside a full Workflow — no rewrite when your requirements grow. Standalone Activities are in Public Preview for Go, Python, Java, TypeScript, and .NET, with Temporal Cloud support included. Full details in the Standalone Activities announcement.
If you are running Redis+Celery for background jobs and tired of debugging disappeared tasks, this is your migration path.
Worker Versioning Is Generally Available
For teams already running Temporal in production, Worker Versioning going GA is the most immediately useful news from Replay 2026. Worker Versioning pins running Workflows to the Worker version that started them. When you deploy new code, in-flight Workflows continue executing on the old Workers until they complete. Your deploy no longer has the potential to break running Workflows mid-execution. Progressive rollouts work cleanly. The entire class of “this deploy corrupted production workflows” incidents goes away. It was one of the most-requested features and it is ready to use today.
Workflow Streams: Streaming for AI Agents
Modern AI agent applications expect streaming output: tokens as the model thinks, tool call progress, intermediate reasoning steps. Building that on top of raw Temporal Signals was technically possible but expensive — one Signal per token adds up fast at production scale.
Workflow Streams is a new durable streaming layer built on Temporal’s Signal and Update primitives. It batch-publishes events to amortize per-Signal cost, deduplicates for exactly-once delivery, and carries state across Continue-As-New for long-running streams. The result: you can stream token output from an LLM activity through a Temporal Workflow to a frontend UI, with full durability and replay guarantees underneath. Currently available as a Python SDK contrib library.
What to Do Now
If you are starting a new project on serverless infrastructure, sign up for the Serverless Workers pre-release and deploy your Workers on Lambda from day one. If you are already running Temporal in production, enable Worker Versioning — it is GA and there is no reason to wait. If you are on Redis+Celery for background jobs, review the Standalone Activities path.
The full list of Replay 2026 announcements is on the Temporal blog, including Task Queue Priority (GA), External Storage for large payloads (Public Preview), and third-party analysis from The New Stack. Temporal has been the most capable workflow engine available for years; it has also required the most operational maturity to run well. Replay 2026 is a direct correction to that trade-off — and the use cases where Temporal excels are now accessible to a much wider range of teams.
