> ## Documentation Index > Fetch the complete documentation index at: https://datum.net/docs/llms.txt > Use this file to discover all available pages before exploring further. # Deploying workloads > Deploy a container image as a workload with datumctl compute deploy, attach Datum's ALB to it, and check its health with datumctl compute workloads. `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. ```bash theme={null} datumctl compute deploy api \ --image=ghcr.io/acme/api:1.4.2 \ --location=us-central-1,us-east-1 \ --min=2 \ --http-port=8080 ``` > [!WARNING] > > 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](https://datum.net/docs/datumctl/compute/building-images.md). To run a standard container image unchanged, add `--runtime-class=general-purpose` — see [Choose a runtime class](https://datum.net/docs/compute/runtimes/overview). If a workload named `api` doesn't exist, this command creates it with one [placement](https://datum.net/docs/compute/placement-and-scaling.md) 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 | Flag | Meaning | | - | - | | `--image` | Container image to deploy, including the registry host, required with the flags path. With `--build`, also where the built image is pushed. | | `--location` | One or more locations to deploy to, comma-separated (`us-central-1,us-east-1`). | | `--city` | Every location in one or more cities, comma-separated (`DFW,IAD`). | | `--location-selector` | Every location whose topology labels match a selector (`topology.datum.net/region=us-east-1`). | | `--min` | Minimum Instances per location (default `1`). | | `--instance-type` | Instance type (default `datumcloud/d1-standard-2`). | | `--runtime-class` | `general-purpose` or `unikernel`. Defaults to `unikernel`, and can't be changed after the workload is created. | | `--network` | Network a new workload attaches to (default `default`). Can't be changed after the workload is created. | | `--http-port` | Port the container serves plain HTTP on. Attaches Datum's ALB to the workload. | | `--no-http` | Remove the workload's ALB. | | `--env` | Set an environment variable as `KEY=VALUE`, or remove one as `KEY-`. Repeat the flag for each variable. Values can contain commas. | | `--env-from-configmap` | Import every key of a ConfigMap as environment variables, as `NAME` or `NAME:PREFIX_`. `NAME-` removes the import. Repeatable. | | `--env-from-secret` | Import every key of a Secret as environment variables, as `NAME` or `NAME:PREFIX_`. `NAME-` removes the import. Repeatable. | | `--configmap` | Mount a ConfigMap as files, as `NAME:/mount/path`. `NAME-` removes the mount. Repeatable. | | `--secret` | Mount a Secret as files, as `NAME:/mount/path`. `NAME-` removes the mount. Repeatable. | | `--label` | Set a label on the workload and its Instances as `key=value`, or remove one as `key-`. Repeatable. Changing a label replaces the workload's Instances. | | `--build` | Build and push the image from a directory (default `.`) before deploying — see [Building images](https://datum.net/docs/datumctl/compute/building-images.md). | | `-f`/`--file` | Deploy from a manifest instead of flags. | | `-y`/`--yes` | Skip the confirmation prompts — needed in scripts and CI. | Pass exactly one of `--location`, `--city`, or `--location-selector`. The `--port` flag isn't supported. Use `--http-port` instead. Environment variables, ConfigMap and Secret imports, mounts, and labels carry forward. A redeploy that doesn't name one keeps the value that the workload already has, so an image update doesn't drop your configuration. To remove one, add a trailing `-`, for example `--env LOG_LEVEL-`. To set a single variable from one key of a Secret, use a manifest. These flags require compute plugin v0.10.7 or later, and you can't combine them with `-f`. > [!NOTE] > > `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: ```text theme={null} Publishing... Backends 2 healthy across us-central-1, us-east-1 Edge programmed Certificate issued https://stark-raven-b7k2m.datumproxy.net ``` 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](https://datum.net/docs/compute/compute-and-alb.md). ## 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](https://datum.net/docs/datumctl/compute/scaling-and-operations.md). 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: ```bash theme={null} datumctl compute deploy -f workload.yaml ``` This path shows a human-readable diff of what would change before touching anything, then asks for confirmation (skip it with `-y`): ```bash theme={null} datumctl compute deploy -f workload.yaml -y ``` > [!TIP] > > A manifest is the only way to reach configuration the flags don't expose — a second placement, additional ports, a custom command, or a variable set from one key of a Secret. 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. > [!WARNING] > > A flag-based `deploy` replaces the workload's whole template and placements with what the flags describe. It keeps environment variables, ConfigMap and Secret imports and mounts, and labels, but it removes 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: ```bash theme={null} # List everything datumctl compute workloads # Only workloads that are degraded right now datumctl compute workloads --health=degraded # Only workloads with a placement in one location datumctl compute workloads --location=us-central-1 ``` 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`: ```bash theme={null} datumctl compute workloads describe api ``` ## Next steps * `datumctl compute deploy --help` and `datumctl compute workloads --help` for the full flag reference. * [Operations](https://datum.net/docs/datumctl/compute/scaling-and-operations.md) — restart, watch a rollout, and inspect individual Instances. * [Destroying workloads](https://datum.net/docs/datumctl/compute/destroying-workloads.md) — tear a workload down when you're done with it. * [Building images](https://datum.net/docs/datumctl/compute/building-images.md) — build and publish the image you're deploying here. This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.