Skip to main content
A Temporal Worker is a long-running process that polls a Task Queue and executes Workflow and Activity code. That model maps directly to a Springwinter Worker container. Updated October 9, 2026. Run the Temporal Service separately; deploy versioned application Workers on Springwinter.

​
Choose the Temporal Service

Use Temporal Cloud for a managed control plane, or connect to a properly operated self-hosted Temporal Service over private networking. The Worker needs the service endpoint, namespace, Task Queue, and either API-key or mTLS configuration. Do not place a Temporal API key or certificate in the image. Supply runtime configuration through environment variables or an appropriate secret-delivery mechanism.

​
Package one Worker process

Build Workflow and Activity code in CI and start the Worker directly in the container. A TypeScript example might use:
Keep Task Queue names explicit. Separate workloads when they need different scaling, dependencies, credentials, or release cadence.

​
Deploy with Springwinter

1

Create a Worker resource

Select the repository and branch containing the Temporal Worker.
2

Configure the connection

Add the Temporal endpoint, namespace, Task Queue, deployment name, build ID, and authentication references at runtime.
3

Choose capacity

Size CPU and memory from Workflow and Activity behavior. External API waits consume different capacity than CPU-heavy media processing.
4

Release safely

Deploy a new Worker version, verify polling and error metrics, then direct compatible traffic according to Temporal Worker Versioning guidance.

​
Worker Versioning

Temporal recommends Worker Versioning for production Workflow changes when your server and SDK versions support it. Versioning keeps existing executions pinned when necessary and allows new executions to move to a new build. A normal rolling container deployment alone cannot guarantee Workflow code compatibility. Deterministic Workflow code must remain compatible with recorded history, or deployments must use Temporal’s versioning and patching mechanisms.

​
Graceful shutdown

On SIGTERM, stop polling, allow Activities to complete or heartbeat cancellation, and close the Worker before the container deadline. Activities should heartbeat when long-running so retries can resume from known progress.

​
Production checklist

  • Run at least two Worker replicas per critical Task Queue when capacity and current product controls allow it.
  • Use separate queues for workloads with different latency or resource profiles.
  • Set Activity timeouts and retry policies explicitly.
  • Heartbeat long-running Activities.
  • Monitor poller availability, schedule-to-start latency, Activity failures, and Worker resource use.
  • Test replay compatibility before promoting Workflow code.

​
Frequently asked questions

Yes, when outbound network access and the required API-key or mTLS configuration are available. Package the SDK Worker as a container and configure the endpoint and namespace at runtime.
No. Temporal provides durable Workflow execution. Springwinter deploys and operates the containerized Worker process that executes your application code.
A rolling deployment replaces containers, but it does not solve Workflow history compatibility. Use deterministic code practices, replay tests, Worker Versioning, or Temporal patching guidance.

​
Sources and further reading

Last modified on October 8, 2026