Deployment

Publish immutable workers and activate compatible job definitions.

Publish the worker build together with the task and job definitions it will execute. The staged flow is:

1. Provision host resources and network/IAM prerequisites.
2. Resolve secrets without putting values in the plan.
3. Publish the immutable worker build.
4. Register definitions and schedules.
5. Wait for worker readiness.
6. Activate schedules and the new service generation.

Pulumi emits provider-native worker publication and registration operations. Each operation records the task ID, task version, build ID, service generation, runtime, limits, and capability evidence. Provider integrations export their native publication mechanism rather than pretending all providers share one deployment API.

Keep the previous build, signing keys, and registrations until in-flight runs finish or are explicitly migrated. Readiness must pass before activation, and an old generation must not be retired while it owns active runs. Rollback activates the previous compatible generation; it does not rewrite run history.

Cloud deployment is opt-in. The local Docker gate proves the selected adapter and its persisted state before any managed account or infrastructure mutation is authorized.

The commerce example selects a Docker-backed job profile and a separate Pulumi/AWS deployment role. See the application configuration for the complete source.