> ## Documentation Index
> Fetch the complete documentation index at: https://www.datum.net/docs/llms.txt
> Use this file to discover all available pages before exploring further.

> ## Agent Instructions
> Agent home for Datum, with what it is, pricing, and how to act: https://agents.datum.net
> If you can only fetch URLs: read https://www.datum.net/docs/llms.txt in full and open the most specific page for the task. Commands, limits, and field paths are on task, operations, and limits pages, not on section overviews. Pages described as "Documentation is coming soon" are placeholders.
> If you have a shell or can save files: download https://www.datum.net/docs/llms-full.txt (every page, about 740 KB) once and search it with grep, instead of fetching pages one at a time.
> datumctl describes itself: `datumctl api-resources` lists resource types and `datumctl explain <resource>` shows a schema. To act on live resources, use Datum MCP or datumctl. To search the docs, use the Docs MCP server at https://www.datum.net/docs/mcp.

# Building images

> Turn a Dockerfile into an image Datum Compute can run, check it for compatibility, and publish it with datumctl compute build.

`datumctl compute build` packages a Dockerfile and build context into an image, and optionally publishes it. Point it at the same Dockerfile you already use for a normal container — no Compute-specific syntax required.

```bash theme={null}
datumctl compute build .
```

`build` is for workloads on the `unikernel` runtime class, the default. That class doesn't run the image as a normal container. It boots the image as a [unikernel](https://www.datum.net/docs/compute/runtimes/unikernels.md), which gives each Instance its own virtual machine with container-like density and startup speed. `build` packages your Dockerfile into the artifact that runtime boots from, and validates it against unikernel requirements as part of the same step — so a missing shared library or the wrong architecture shows up as a build-time error instead of a workload that never comes up.

Workloads on the `general-purpose` runtime class run standard container images, so they don't need `build`. Push the image with the tools that you already use. For more information, see [Choose a runtime class](https://www.datum.net/docs/compute/runtimes/overview).

> [!NOTE]
>
> `build` needs a BuildKit backend to run: Docker Desktop or Docker Engine with BuildKit enabled (the default on modern installs), a standalone `buildkitd`, or `BUILDKIT_HOST` pointing at one.

With no `--output`, this is a **local debug build**: it packages the image so you can confirm it builds successfully, without writing or publishing anything. Once you're ready to deploy it, add `--output` or move on to [deploying workloads](https://www.datum.net/docs/datumctl/compute/deploying-workloads.md).

## Choosing a Dockerfile

By default, `build` looks for `Dockerfile.datum` in the build context and falls back to `Dockerfile` if that file does not exist — a convenient way to keep a Compute-specific variant alongside your normal one without extra flags. Use `-f` to point at a Dockerfile anywhere else:

```bash theme={null}
# Use a Dockerfile in a non-default location
datumctl compute build -f ./deploy/Dockerfile .

# Pass build-time variables used by ARG instructions
datumctl compute build --build-arg VERSION=1.2.3 .

# Package a specific stage of a multi-stage Dockerfile (default: the final stage)
datumctl compute build --target production .
```

## Writing the output somewhere

`--output` (`-o`) accepts three kinds of destination:

| Destination | Example |
| - | - |
| Registry reference | `--output ghcr.io/acme/api:latest` |
| OCI archive (`.tar`) | `--output ./compute-image.tar` |
| OCI layout directory | `--output ./compute-image` |

```bash theme={null}
# Publish straight to a registry
datumctl compute build --push --output ghcr.io/acme/api:latest .

# Write a portable OCI archive instead
datumctl compute build --output ./compute-image.tar .
```

> [!WARNING]
>
> When `--output` is a registry reference, `build` asks for confirmation before pushing. Pass `--push` to skip that prompt — required in CI, where there is no terminal to confirm on.

## Checking compatibility before you package it

`--analyze` inspects the built entrypoint for the kind of problem that only shows up once Compute's unikernel runtime tries to boot the image — a binary built for the wrong architecture, a startup script whose interpreter is missing, or a shared library the final stage never copied in:

```bash theme={null}
datumctl compute build --analyze .
```

Where a fix is a mechanical Dockerfile edit, the finding shows exactly what to change:

```text theme={null}
error[missing-libs]: /app/server requires a runtime file that is not present in the image
 --> Dockerfile:8
  | copy missing runtime files into the final image
  | - COPY --from=build /app /app
  | + COPY --from=build /app /app
  | + COPY --from=build /lib/x86_64-linux-gnu/libc.so.6 /lib/x86_64-linux-gnu/libc.so.6
```

Reach for `--fix` once you're ready to apply changes like that automatically — it edits the selected Dockerfile in place and rebuilds. `--fix` implies `--analyze`, and only ever applies safe, exact-line edits — it will never restructure your Dockerfile.

```bash theme={null}
datumctl compute build --fix .
```

## Inspecting a published image

`build inspect <image>` is a diagnostic for an image that already exists in a registry — useful when a deployment isn't starting and you want to confirm the image itself is the problem before looking at the workload. It reports the same kind of compatibility findings as `--analyze`, plus the packaged filesystem and startup configuration Compute will boot from. Add `--extended` for additional OCI metadata — the image index, manifest digest, and layer count. Inspection never downloads the packaged filesystem layer itself, so it stays fast even against a large image.

```bash theme={null}
datumctl compute build inspect ghcr.io/acme/api:1.4.2
```

## Next steps

* `datumctl compute build --help` and `datumctl compute build inspect --help` for the full flag reference.
* [Deploying workloads](https://www.datum.net/docs/datumctl/compute/deploying-workloads.md) — take a published image and run it as a workload.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.