datumctl compute deploy takes a container image and runs it as a workload across one or more cities. It supports two ways of describing what to deploy — flags, or a manifest file for the declarative form — and both converge on the same underlying workload.
--image must point to an image produced by datumctl compute build, not a standard OCI image from docker build — see Building images. Compute boots workloads as unikernels, which requires the packaged filesystem and startup metadata compute build adds during packaging.api doesn’t exist yet, this creates it with one placement (default) spanning both cities, each running at least 2 instances. Run the same command again with a new --image and it updates the existing workload instead — deploy is create-or-update, the same idempotent shape as datumctl apply elsewhere in the CLI.
Flags at a glance
deploy needs a network to attach the workload to. If none exists yet in the project, it offers to create a minimal one, with IP addresses assigned automatically, on your behalf — pass -y to accept that automatically in a non-interactive run.
Watching the rollout
deploy waits and prints progress as instances come up, the same view datumctl compute rollout shows on demand — see Operations. Ctrl-C detaches from the watch without canceling anything; the rollout keeps going in the background; run datumctl compute rollout api any time to reattach.
Deploying from a manifest
A flag-based deploy writes a workload.yaml in the current directory after it succeeds — the same Workload resource the flags produced, expressed as YAML. Point -f at a manifest to deploy from it instead of flags:
This path shows a human-readable diff of what would change before touching anything, then asks for confirmation (skip it with -y):
A manifest is the only way to reach configuration the flags don’t expose — a second placement, additional ports, or environment variables. Edit the generated workload.yaml (or write one from scratch) and apply it with -f.
Checking workload health
datumctl compute workloads lists every workload in the project, with per-city ready counts rolled into a single health summary:
Health is one of available, degraded, progressing, or unknown. For the full picture on a single workload — its container spec, scale settings, and per-city ready/desired counts together — use describe:
Next steps
datumctl compute deploy --help and datumctl compute workloads --help for the full flag reference.- Operations — restart, watch a rollout, and inspect individual instances.
- Destroying workloads — tear a workload down when you’re done with it.
- Building images — build and publish the image you’re deploying here.
