Upgrade to Workload names

The shared record for Jobs, Services, and VMs is now called Workload. Update API consumers, Python code, and runtime scripts together with the CLI and API. The old names have no compatibility aliases.

Worker management retains its current names and behavior. A native Kubernetes apps/v1 Deployment still runs a Worker's persistent container. Job execution, retry, resubmission, Service upgrades, and VM recovery keep their existing behavior.

API and Python changes

Previous name	New name
/v1/deployments and its subordinate routes	/v1/workloads and the same subordinate routes
/v1/deployment-costs	/v1/workload-costs
JSON deploymentType, deploymentId, deployment	workloadType, workloadId, workload
JSON deploymentIds, deploymentCount, deploymentsWithoutPrice	workloadIds, workloadCount, workloadsWithoutPrice
Python DeploymentsApi, DeploymentAdmissionApi	WorkloadsApi, WorkloadAdmissionApi
Python deployment_id=	workload_id=
Python job.status().deployment	job.status().workload
Python DeploymentWaitTimeout	WorkloadWaitTimeout
Python wait_for_terminal_deployment	wait_for_terminal_workload
Python anycloud_workflows.deployments	anycloud_workflows.workloads

Generated operations and models also use Workload names, such as submit_workload_sync, get_workload_status_sync, and WorkloadStatusResponse. API admission errors use WORKLOAD_ADMISSION_* and WORKLOAD_ID_CONFLICT. Management errors use WORKLOAD_MANAGEMENT_*. Worker execution endpoints retain their existing WORKLOAD_* errors.

For example:

from anycloud import Client
from anycloud_workflows import WorkloadWaitTimeout

with Client() as client:
    job = client.submit(worker="model-worker", workload_id="inference-42")
    print(job.status().workload.state)
    try:
        job.wait(timeout_seconds=300)
    except WorkloadWaitTimeout:
        print("The Job is still running")

The existing CLI commands, including job, service, vm, list, status, and worker, keep their names. Their JSON output uses the new field names.

Environment variables

Previous variable	New variable	Purpose
ANYCLOUD_DEPLOYMENT_ID	ANYCLOUD_WORKLOAD_ID	Default target for CLI commands
DEPLOYMENT_ID	WORKLOAD_ID	ID injected into workload containers; hosted API identity input
ANYCLOUD_MANAGED_K8S_HOST_DEPLOYMENT_ID	ANYCLOUD_MANAGED_K8S_HOST_WORKLOAD_ID	Managed Kubernetes supervisor's host ID

Update shell scripts, container entrypoints, environment files, and custom API launchers. Built-in launchers supply the new names automatically. Keep the existing ID value when updating a hosted API launcher so its database identity continues to match.

Existing VM containers retain the environment they were created with until replacement. Update images and scripts before upgrading or recreating those containers; newly created containers receive WORKLOAD_ID. Worker reconciliation applies the new environment to the native Kubernetes Deployment template, which can replace its Pod. Prepare Worker images for that change before the API upgrade. Stored commands and user environment values are preserved by the database migration, so references to old variable names in them require your own update.

Upgrade order and database

1. Prepare updated application code and images, including applications that use the Python SDK. Retain a consistent backup of api.db and its matching cipher.key with the database writer stopped before upgrading.
2. Run anycloud update, then anycloud api update to update the selected API and its local manager. See API updates for custom installations and hosted API requirements.
3. Install the matching anycloud-sdk version in each Python environment and use the updated images. CLI, API, and SDK versions must match. Recreate or upgrade containers as needed to apply the environment changes above.
4. Update any direct database queries or operator tooling. Migration 0105_rename_deployments_to_workloads.sql runs automatically on startup. It renames deployments to workloads, deployment_events to workload_events, deployment_type to workload_type, and ownership columns deployment_id to workload_id, including those in vms and container_specs.

The migration preserves records, IDs, event history, encrypted values, and Worker ownership. Existing cloud resource IDs, DNS names, provider metadata keys, Kubernetes names, and bucket paths remain valid. Do not rename provider tags or move existing data directories to match the new API vocabulary.

Migrations are forward-only. An older API cannot use the renamed database. Returning to an older release requires restoring the database and matching key from the backup taken before the upgrade.