Skip to main content
Compute is in preview, and each project needs approved access before it can deploy. For product guides, including a quickstart, see Compute.
datumctl compute deploys a container image as a workload that runs in one or more Datum Cloud locations, and provides the day-to-day commands to scale, restart, and delete it. It’s a first-party plugin instead of a built-in command. After you install it, its commands behave like the rest of the CLI.
New to plugins? Using plugins covers installation, upgrades, and how a plugin inherits your active context and credentials. Not installed datumctl itself yet? Start with the Quickstart.

​
Core concepts

A handful of terms recur across every compute command: compute is project-scoped: every command reads --project (or your active context’s project, injected automatically — see Contexts & scoping). There is no organization-level view and no --namespace flag; all compute resources live in the project’s default namespace.

​
Requesting access

Compute is a gated service. The first time you run a command that needs it, datumctl checks whether your project is entitled to use Compute:

Not requested

No request has been made yet. On an interactive terminal, the gate offers to submit one for you.

Pending approval

A request is awaiting a manual decision by the service provider. Latency is unbounded.

Active

The project is entitled — every compute command runs normally.

Denied / Revoked

The provider rejected the request (or later revoked it). Recovery is submitting a new request.

​
The automatic gate

Run any gated command — deploy, workloads, instances, and so on — without access, and on a TTY datumctl prompts you inline:
datumctl checks if Compute is enabled for the project, and — if not — asks whether to request access; on confirmation, it submits the request and waits briefly to see whether the platform approves it immediately or the request needs manual review. Decline, and nothing is submitted — run datumctl compute access request yourself whenever you’re ready. In a non-interactive shell (CI, a script, or a piped command), the gate never prompts; it fails immediately and tells you which command to run.

​
Checking and requesting access explicitly

Use datumctl compute access to check the current state directly, and access request for more control over submitting one than the automatic prompt gives you:
datumctl compute access prints the state, the platform’s explanation, and — when there’s a next step — the exact command to run:
Add -o json or -o yaml to script against the state instead of parsing prose.

​
Checking quota

Once active, datumctl compute quota shows how much of your project’s compute allotment is used:
Pass --constrained to show only the resource types that are currently at their limit — the fastest way to check whether a stalled rollout is a quota problem:

​
Find your way around

Building images

Turn a Dockerfile into an image Compute can run, and check compatibility before you deploy.

Deploying workloads

Deploy a workload from flags or a manifest, and read back its health across locations.

Operations

Roll restarts, watch a rollout, and debug individual Instances.

Destroying workloads

Tear down a workload and every Instance it created.
  • datumctl compute --help and datumctl compute <command> --help for the full flag reference.
  • Compute — product guides for runtime classes, configuration, placement, and publishing workloads.
  • Using plugins — how the compute plugin is installed, upgraded, and trusted.
  • Contexts & scoping — how the project a compute command runs against is resolved.
  • Output formats & scripting — -o json/-o yaml patterns that apply across compute subcommands.
Last modified on September 23, 2026