Worker Versioning solves challenges by helping users manage different builds or versions of their Workflows, while:

Ramping traffic gradually to a new Worker Deployment Version.
Verifying a new Deployment Version with tests before sending production traffic to it.
Instant rollback when you detect that a new Deployment Version is broken.

This launch also includes the Public Preview of two new capabilities under the umbrella of Worker Versioning – Worker Controller Autoscaling and Upgrade-on-Continue-as-New.

Worker Controller Autoscaling

The Temporal Worker Controller is an open-source Kubernetes operator that automates this coordination. Push a new image, and it creates a new versioned Kubernetes Deployment, works with Temporal to progressively ramp traffic to the new version, and automatically sunsets old versions when they’re safe to remove. With autoscaling, the Worker Controller now lets you attach Kubernetes resources, such as Horizontal Pod Autoscalers (HPAs) or PodDisruptionBudgets (PDBs), to your versioned worker deployments automatically. Additionally, we've added worker_version labels to the approximate_backlog_count metric so that it's possible to independently scale each versioned Deployment based on its own specific backlog depth.

Upgrading on Continue-as-New (UCAN)

Long-running Workflows that use Continue-as-New can upgrade to newer Worker Deployment Versions at Continue-as-New boundaries without requiring patching. This pattern is ideal for:

Entity Workflows that run for months or years
Batch processing Workflows that checkpoint with Continue-as-New AI agent Workflows with long sleeps waiting for user input

OpenAI Agents SDK sandbox integration is in Public Preview