Workflows
The Workflows section of the console lets you create container workflows from a YAML definition and watch them run — viewing the execution diagram, per-step status, and live logs.
The Workflows explorer
Workflows live in the Workflows section of the left explorer sidebar.
- Header: a refresh button re-lists your workflows.
- Empty state: when there are none, the section shows "No workflows yet" with a New workflow button.
- New workflow: available from the empty-state button, the section's right-click menu, and the Resources menu in the menu bar.
- Workflow node: shows a colored status dot and the workflow name. Expanding it reveals the Diagram and Logs entries.
Creating a workflow
Choose New workflow and pick a local YAML file (.yaml / .yml). The console reads the file and uploads its contents to the engine, which validates the definition and pulls the required images.
name: hello-world
steps:
- name: greet
platform: docker # docker | podman | singularity | apptainer
image: hello-world
Definition fields:
| Field | Description |
|---|---|
name | Workflow name (required) |
tags | Optional list of tags |
steps[] | One or more steps (required) |
Each step accepts: name, platform (default docker), mode (parallel or sequential, default sequential), image, command, volumes (name/host/container/mode), ports (name/host/container/protocol), env, and resources (cpu, memory, gpu). volumes and ports are objects that each require a name — a stable label used to target the mapping in an override.
hub://<name>), or a URL, use the CLI (dxflow workflow create --identity <id> <source>) or the API (source parameter). Browse the hub with dxflow workflow hub search and dxflow workflow hub inspect <name>.Per-run overrides
Some launch-time values can be tuned per run without editing the definition, via a workflow.ini file in the workflow's folder (edit it under Artifacts). It is read only at start — changes take effect on the next start, not on a running workflow. Four categories are supported, each scoped to a step by its name:
[volume]
step-name.data = /mnt/host/data
[port]
step-name.web = 9090
[env]
step-name.KEY = value
[resource]
step-name.cpu = 8
step-name.memory = 8g
[volume]/[port] replace the host side of a named volume/port (container side stays); [env] sets or replaces an environment variable; [resource] replaces cpu, memory, or gpu. The image and command are not overridable. Overrides can also be passed when starting from the CLI (--override) or API.
Overrides never modify the workflow definition (workflow.json) — they are merged into the launch only. If an override targets a step name, volume, or port that does not exist, or gives an invalid cpu/memory/gpu value, the start fails with an override: … error.
Inspecting a workflow
Expanding a workflow opens two views as tabs (logs open in the secondary pane):
A read-only layout grouped by phase. Each step is a card showing its status dot, platform, image, duration, and resource/volume/port/env bindings.
A live stream of combined stdout/stderr for the workflow's steps.
Statuses
Workflow status is one of created, started, stopped, exited. Step status is one of pending, running, exited.
Lifecycle actions
Right-click a workflow node — or use the buttons on its step cards — to start, stop, and remove it. A step card can also open a shell into its container.
The same operations are available from the CLI and API:
dxflow workflow start <identity>
dxflow workflow stop <identity>
dxflow workflow remove <identity>
See the Workflow CLI reference and Workflow API for the full set of operations.
Supported platforms
Steps can target Docker, Podman, Singularity, or Apptainer, selected per step via the platform field.