Skip to main content
datumctl compute deploy takes a container image and runs it as a workload across one or more locations. 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.
A new workload without --runtime-class runs on the unikernel runtime class. For that class, --image must point to an image produced by datumctl compute build, not a standard OCI image from docker build — see Building images. To run a standard container image unchanged, add --runtime-class=general-purpose — see Choose a runtime class.
If a workload named api doesn’t exist, this command creates it with one placement named default that spans both locations, runs at least two Instances in each location, and attaches Datum’s ALB to it. If you run the same command again with a new --image, it updates the existing workload. Like datumctl apply, deploy creates or updates.

​
Flags at a glance

Pass exactly one of --location, --city, or --location-selector. The --port flag isn’t supported. Use --http-port instead.
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.

​
Attaching an ALB

--http-port declares the port your container serves plain HTTP on, and attaches Datum’s ALB to the workload. Datum terminates TLS, so don’t serve HTTPS on that port. After the rollout, deploy prints the progress of publishing and then the ALB’s hostname, on its own line, as the last line of output:
Redeploying without --http-port keeps the workload’s current port and its ALB. To remove the ALB, pass --no-http. Without an HTTP port, the workload isn’t reachable from the internet. For custom domains and publishing workloads you manage with manifests, see Publish a workload.

​
Watching the rollout

deploy waits and prints progress as Instances come up, the same view datumctl compute rollout shows on demand. For more information, see Operations. Press Control+C to detach from the watch. The rollout continues in the background. To reattach, run datumctl compute rollout api.

​
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.
A manifest deploy doesn’t create or remove an ALB. You can’t combine -f with --http-port, --no-http, --runtime-class, --network, or --build. Set the runtime class and network in the manifest instead.
A flag-based deploy replaces the workload’s whole template and placements with what the flags describe. It removes environment variables, volumes, registry credentials, custom commands, and extra placements that you set in a manifest, and it sets the Instance count to the --min value, which defaults to 1. Once you manage a workload with a manifest, update it with datumctl compute deploy -f workload.yaml. Each flag-based deploy also overwrites workload.yaml in the current directory, so keep edited manifests under another name.

​
Checking workload health

datumctl compute workloads lists every workload in the project, with per-location ready counts rolled into a single health summary:
The HEALTH column shows Available, Degraded, Unavailable, or Unknown. The --health flag takes the lowercase form, such as --health=degraded. The URL column shows each workload’s ALB hostname. For the full picture on a single workload — its container spec, scale settings, ALB hostname, and per-location 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.
Last modified on September 23, 2026