Skip to main content
Everything you run on Control Plane is a workload: the unit you deploy, scale, route traffic to, and read logs from. Two choices shape everything else about it: the type it is created as, and the identity attached to it.

​
How It Fits

A workload, my-app, drawn as one box holding two containers, app and sidecar, which reach each other over localhost. Up to eight containers in one workload: they deploy, scale, and stop together. The endpoint, the firewall, and the identity belong to the whole workload. Editing the workload creates a new version, and every location rolls it out beside the version already serving: The same workload, my-app, at two moments. While the update rolls out, version 6 is ready and serving and version 7 rolls out beside it, not ready. When the update reports ready, only version 7 remains, in a smaller box. The live version keeps serving while the update rolls out, then traffic switches over, and the old version drains. The workload keeps serving through every update, even a broken one. The type, chosen at creation, decides how the workload scales, serves traffic, and updates:

​
Key Behaviors

  • A broken update cannot take the workload down. Each location keeps serving the last healthy version until the new one reports ready, which your health probes define; then traffic switches to the new version and the old one drains, with no gap in service. Rollout options set how many replicas turn over at once, and with dynamic tags, pushing a new image under the same tag starts the rollout by itself.
  • Per-location differences are overrides, not separate workloads. Local options name a location and restate any of the default options, so one region can run a wider replica range than the rest. Suspend the workload to stop every location, or set it in one location’s overrides to stop that location alone; the workload then reports partiallySuspended.
  • Scale-to-zero depends on the type. A serverless workload scales to zero on any metric it supports. standard and stateful reach zero only through KEDA, which the GVC must have enabled first. cron and vm cannot reach zero at all, and minScale: 0 is rejected with workloads of type 'vm' are unable to scale to zero, please set minScale > 0.
  • Capacity AI right-sizes what autoscaling does not. It moves CPU and memory between their minimum and maximum from historical usage, which is why it cannot run alongside CPU-based autoscaling: the combination is rejected with CapacityAI may not be enabled when the autoscaling metric is 'cpu', and GPU containers exclude it too. Because sizing follows history, a sudden spike can outrun the current allocation until Capacity AI raises it.
  • Nothing reaches a workload until its firewall allows it. Other workloads address it at my-app.my-gvc.cpln.local over mutual TLS, but the internal firewall defaults to none. Open it to same-gvc, same-org, or a workload-list naming exact workloads, which can cross GVCs. Public traffic is a separate external firewall decision.
  • A global endpoint and one per location come built in. The global one is the canonical endpoint: one HTTPS URL that sends each request to the nearest healthy location. Each location publishes an HTTPS endpoint of its own, and a domain route puts a hostname you own in front of the workload, with its TLS certificate issued for you.
  • Control Plane retries and times out requests for you. A request that fails to connect to the workload is retried, twice by default, and a request the workload has not answered within 5 seconds fails. The retry policy and the timeout are both workload settings.
  • Logs, metrics, and a shell are built in. Every replica streams logs and metrics automatically, containers can publish custom metrics of their own, and cpln workload connect opens a shell in a running replica.

​
Gotchas

  • The type cannot be changed after creation. A request that edits the type is rejected with Workload type may not be changed. Switching means creating a second workload, so capture the old spec first.
  • A serverless workload must expose exactly one port, in one container. No port at all is rejected with workloads of type 'serverless' must have at least one container port exposed., and so is a second port or a second container with ports; portless background work belongs in a standard workload.
  • A cron workload runs its schedule in every location the GVC spans. The one per-location override that applies is suspend, which stops the schedule in that location alone.
  • A missing secret pauses the deployment rather than failing it. A cpln://secret/my-secret reference the workload’s identity cannot yet reveal holds the rollout until access is granted; cpln workload force-redeployment clears it once it is.
  • Replicas, CPU, and memory are quota’d per workload. The replica quota caps autoscaling’s maxScale, the CPU and memory quotas cap the totals across all containers, and all three are raised on request rather than by editing the spec; the quota catalog lists the defaults.

​
Learn More

Workload reference

Every field: containers, options, endpoints, rollout, suspend, and tags.

Create a Workload

Deploy an image from the Console, the CLI, or a manifest.

Workload types

What each type can expose, how it scales, and how it updates.

GVC (Global Virtual Cloud)

The locations a workload runs in, and the settings every workload in a GVC shares.