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. It opens a dialog offering both ways to create one.
• 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

New workflow opens a dialog with two sections, one open at a time. It starts on Upload a definition and afterwards reopens on whichever section you used last.

• Upload a definition — drop a YAML file (.yaml / .yml) on the upload area, or click it to pick one. The console reads the file and uploads its contents to the engine.
• Deploy from the hub — the dxflow hub catalog, a curated set of ready-to-run templates spanning genomics, molecular dynamics, structural biology, data science, and more. The catalog loads the first time you open this section. Type to filter by name, description, category, or tag, then click an entry to deploy it; the console passes its hub://<name> address to the engine, which reads the definition straight from the catalog on GitHub.

Either way the engine 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:

Step fields:

Each volumes and ports entry requires a name — a stable label used to target the mapping in an override.

A volume's host is a path on the engine host. A relative one is resolved against the engine's directory (~/.dxflow), so ./volume is the engine volume itself — the root of what Artifacts shows — and ./volume/data is the data/ directory an upload writes to. A path outside the volume, relative or absolute, is mounted as given but stays out of reach of dxflow artifact.

volumes:
  - name: data
    host: ./volume/data # ~/.dxflow/volume/data, the `data/` of Artifacts
    container: /data
    mode: ro            # optional; read-write by default

link names one of the step's ports to publish on a licensed subdomain, reachable over HTTPS from anywhere. It is assigned when a start asks for links — 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

image and command are not overridable. The same values can be passed at start time from the CLI (--override) or the 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.

A limit larger than the machine the engine runs on is a different failure: the runtime refuses to start the step. A start can cap them instead, lowering any step's cpu or memory that exceeds the host's core count or total memory.

• Every start from the console does this. From the CLI and API it is asked for, with dxflow workflow start <identity> --fit or fit on the request.
• Applied after the overrides, so a [resource] value set too high is capped too.
• Holds for that start only; never written back to workflow.ini.
• Steps already within the host's capacity are untouched, and gpu is never changed.

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, including any shell opened on one of its steps.

Two more entries appear once links are in play: 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.

Every start the console makes — from the node menu or a step card, with or without a link — caps each step's cpu and memory to what the engine's machine has, so a definition asking for more still runs. See Per-run overrides.

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.