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, the workflow name, and when it was created. A link icon marks a workflow publishing on a link. Clicking it opens the workflow's Diagram and Logs.

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. The workflow opens on its Diagram as soon as it exists, and its folder — definition, overrides, and outputs — lives under Artifacts.

name: hello-world
steps:
  - name: greet
    runtime: docker          # docker | podman | singularity | apptainer
    image: hello-world

Definition fields:

Each step accepts: name, runtime (default docker), mode (parallel or sequential, default sequential), image, command, volumes (name/host/container/mode), ports (name/host/container/protocol), env, resources (cpu, memory, gpu), and link. volumes and ports are objects that each require a name — a stable label used to target the mapping in an override. link names one of the step's ports to publish on a licensed subdomain, reachable over HTTPS from anywhere — assigned when a start asks for links, with Start with link in the console or dxflow workflow start <identity> --link. See Links.

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

Opening a workflow gives you two views — the diagram as a tab in the main pane, the logs as a tab in the secondary pane:

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 to start, stop, and remove it — removing asks for confirmation, then stops its containers and closes its tabs. Start with link starts and publishes each step declaring one, available while the license carries links, and Open link lists what the workflow publishes, one entry per step.

Step cards carry their own controls: Start on the first step while the workflow is created, stopped, or exited, Start with link beside it when the definition declares one, Stop on the latest running step while the workflow is started, and Shell on a running step, which opens a terminal inside that step's container as a new entry under Shells.

The same operations are available from the CLI and API:

dxflow workflow start <identity>
dxflow workflow start <identity> --link
dxflow workflow stop <identity>
dxflow workflow remove <identity>

See the Workflow CLI reference and Workflow API for the full set of operations.

Supported runtimes

Steps can target Docker, Podman, Singularity, or Apptainer, selected per step via the runtime field.