Deployment

Route Release Pinning

Bind public workflow admission to the caller release and immutable worker compatibility facts across rolling deploys and retries.

The caller names its release. The run keeps that fact for its entire life.
Admission
Exact live deployment identity from the trigger body
Execution
Worker build and compatibility set pinned on the run
Retry
Same idempotency key resolves the same release-bound run

Worker compatibility prevents the wrong worker from executing a task. Caller release pinning closes the other half of version skew.

Configure the runtime identity

workflow_runtime:
  worker_compatibility:
    mode: enforced
    require_caller_deployment_id: true
    build_id: build-2026-08-25.1
    deployment_id: prod-us-east-1-wave-1
    compatibility_set: workflow-v3
    can_execute_sets:
      - workflow-v3
      - workflow-v2

Use a unique build/deployment pair for every release. In enforced mode, the current compatibility set must appear in can_execute_sets.

Trigger contract

The canonical workflow trigger body accepts external_deployment_id (maximum 128 characters). Generic HTTP headers are never consulted. When require_caller_deployment_id is enabled, an absent id fails closed.

Ductor accepts only a server-declared live identity. A building, failed, canceled, expired, wrong-tenant, wrong-environment, or mismatched identity returns a typed failure. There is no fallback to whichever code is current and no second pending-run state machine.

{
  "subject_type": "order",
  "subject_id": "order-4821",
  "idempotency_key": "order-4821-created",
  "external_deployment_id": "prod-us-east-1-wave-1",
  "input": { "order_id": "order-4821" }
}

The admitted run persists caller deployment, worker build/deployment, compatibility set, and shard identity. Child workflows inherit the requirement unless an explicit governed boundary replaces it.

Retry and rollout safety

Idempotency keys are capped at 2048 bytes at both API and database boundaries. An exact-key retry resolves the existing run before new-run capacity gates and verifies the originally pinned deployment, so a saturated tenant can safely retry without retargeting work.

Rolling releaseNew work advances while old work drains safely
  1. Publish

    Declare the new deployment identity and start compatible workers.

  2. Route

    Send new callers with the new external_deployment_id.

  3. Drain

    Keep old workers alive while their pinned runs remain nonterminal.

  4. Retire

    Remove the old set only after audit proves the drain is complete.

Rollback restores the prior build and routes new calls with its live identity. It does not mutate existing run facts.

No recency-based compatibility

Ductor never infers that the newest deployment is compatible. Release identity, compatibility set, and durable run pins are independent explicit facts.