Struct Node 

pub struct Node {

    pub id: NodeId,
    pub name: Option<String>,
    pub description: Option<String>,
    pub path: Option<String>,
    pub path_sha256: Option<String>,
    pub args: Option<String>,
    pub env: Option<BTreeMap<String, EnvValue>>,
    pub operators: Option<RuntimeNode>,
    pub operator: Option<SingleOperatorDefinition>,
    pub ros2: Option<Ros2BridgeConfig>,
    pub custom: Option<CustomNode>,
    pub outputs: BTreeSet<DataId>,
    pub output_types: BTreeMap<DataId, String>,
    pub output_framing: BTreeMap<DataId, OutputFraming>,
    pub inputs: BTreeMap<DataId, Input>,
    pub input_types: BTreeMap<DataId, String>,
    pub output_metadata: BTreeMap<DataId, Vec<String>>,
    pub pattern: Option<String>,
    pub send_stdout_as: Option<String>,
    pub send_logs_as: Option<String>,
    pub min_log_level: Option<String>,
    pub max_log_size: Option<String>,
    pub max_rotated_files: Option<u32>,
    pub build: Option<String>,
    pub git: Option<String>,
    pub hub: Option<String>,
    pub branch: Option<String>,
    pub tag: Option<String>,
    pub rev: Option<String>,
    pub restart_policy: RestartPolicy,
    pub shared_memory_pool_size: Option<ByteSize>,
    pub max_restarts: u32,
    pub restart_delay: Option<f64>,
    pub max_restart_delay: Option<f64>,
    pub restart_window: Option<f64>,
    pub health_check_timeout: Option<f64>,
    pub finish_grace_secs: Option<f64>,
    pub module: Option<String>,
    pub params: BTreeMap<String, String>,
    pub cpu_affinity: Option<Vec<usize>>,
    pub deploy: Option<Deploy>,
}

Dora Node Configuration

A node represents a computational unit in a Dora dataflow. Each node runs as a separate process and can communicate with other nodes through inputs and outputs.

Fields

id: NodeId

Unique node identifier. Must not contain / characters.

Node IDs can be arbitrary strings with the following limitations:

• They must not contain any / characters (slashes).
• We do not recommend using whitespace characters (e.g. spaces) in IDs

Each node must have an ID field.

Example

nodes:
  - id: camera_node
  - id: some_other_node

name: Option<String>

Human-readable node name for documentation.

This optional field can be used to define a more descriptive name in addition to a short id.

Example

nodes:
  - id: camera_node
    name: "Camera Input Handler"

description: Option<String>

Detailed description of the node’s functionality.

Example

nodes:
  - id: camera_node
    description: "Captures video frames from webcam"

path: Option<String>

Path to executable or script that should be run.

Specifies the path of the executable or script that Dora should run when starting the dataflow. This can point to a normal executable (e.g. when using a compiled language such as Rust) or a Python script.

Dora will automatically append a .exe extension on Windows systems when the specified file name has no extension.

Example

nodes:
  - id: rust-example
    path: target/release/rust-node
  - id: python-example
    path: ./receive_data.py

URL as Path

The path field can also point to a URL instead of a local path. In this case, Dora will download the given file when starting the dataflow.

Note that this is quite an old feature and using this functionality is not recommended anymore. Instead, we recommend using a git and/or build key.

path_sha256: Option<String>

SHA-256 checksum the path download must match, verified after fetch and on cache reuse (spec §8.2/§8.4). Set internally when a hub: reference resolves to a prebuilt binary artifact; rarely set by hand.

args: Option<String>

Command-line arguments passed to the executable.

The command-line arguments that should be passed to the executable/script specified in path. The arguments should be separated by space. This field is optional and defaults to an empty argument list.

Example

nodes:
  - id: example
    path: example-node
    args: -v --some-flag foo

env: Option<BTreeMap<String, EnvValue>>

Environment variables for node builds and execution.

Key-value map of environment variables that should be set for both the build operation and the node execution (i.e. when the node is spawned through path).

Supports strings, numbers, and booleans.

Example

nodes:
  - id: example-node
    path: path/to/node
    env:
      DEBUG: true
      PORT: 8080
      API_KEY: "secret-key"

operators: Option<RuntimeNode>

Multiple operators running in a shared runtime process.

Operators are an experimental, lightweight alternative to nodes. Instead of running as a separate process, operators are linked into a runtime process. This allows running multiple operators to share a single address space (not supported for Python currently).

Operators are defined as part of the node list, as children of a runtime node. A runtime node is a special node that specifies no path field, but contains an operators field instead.

Example

nodes:
  - id: runtime-node
    operators:
      - id: processor
        python: process.py

operator: Option<SingleOperatorDefinition>

Single operator configuration.

This is a convenience field for defining runtime nodes that contain only a single operator. This field is an alternative to the operators field, which can be used if there is only a single operator defined for the runtime node.

Example

nodes:
  - id: runtime-node
    operator:
      id: processor
      python: script.py
      outputs: [data]

ros2: Option<Ros2BridgeConfig>

ROS2 bridge configuration (unstable).

Declares this node as a ROS2 bridge that automatically subscribes to or publishes on ROS2 topics. No custom code is needed – the framework spawns a bridge binary that converts between ROS2 DDS messages and Dora’s Arrow format.

Example

nodes:
  - id: camera_bridge
    ros2:
      topic: /camera/image_raw
      message_type: sensor_msgs/Image
      direction: subscribe
    outputs:
      - image

custom: Option<CustomNode>

Legacy node configuration (deprecated).

Please use the top-level path, args, etc. fields instead.

outputs: BTreeSet<DataId>

Output data identifiers produced by this node.

List of output identifiers that the node sends. Must contain all output_id values that the node uses when sending output, e.g. through the send_output function.

Example

nodes:
  - id: example-node
    outputs:
      - processed_image
      - metadata

output_types: BTreeMap<DataId, String>

Optional type annotations for outputs.

Maps output identifiers to type URNs (e.g. std/media/v1/Image). Only annotated outputs are type-checked; unannotated outputs remain dynamic.

output_framing: BTreeMap<DataId, OutputFraming>

Per-output framing overrides (default: Raw for all).

Maps output identifiers to their wire framing mode. Outputs not listed here use the default Raw framing.

inputs: BTreeMap<DataId, Input>

Input data connections from other nodes.

Defines the inputs that this node is subscribing to.

The inputs field should be a key-value map of the following format:

input_id: source_node_id/source_node_output_id

The components are defined as follows:

• input_id is the local identifier that should be used for this input.

  This will map to the id field of Event::Input events sent to the node event loop.

• source_node_id should be the id field of the node that sends the output that we want to subscribe to

• source_node_output_id should be the identifier of the output that that we want to subscribe to

Example

nodes:
  - id: example-node
    outputs:
      - one
      - two
  - id: receiver
    inputs:
        my_input: example-node/two

input_types: BTreeMap<DataId, String>

Optional type annotations for inputs.

Maps input identifiers to expected type URNs. Used by dora validate to check that upstream output types match expectations.

output_metadata: BTreeMap<DataId, Vec<String>>

Required metadata keys per output.

Maps output identifiers to lists of required metadata key names. These are checked at build/validate time.

Example

output_metadata:
  response: [request_id]

pattern: Option<String>

Communication pattern shorthand (e.g. service-server).

Automatically implies required metadata keys on all outputs. See pattern_metadata_keys() for supported patterns.

send_stdout_as: Option<String>

Redirect stdout/stderr to a data output.

This field can be used to send all stdout and stderr output of the node as a Dora output. Each output line is sent as a separate message.

Example

nodes:
  - id: example
    send_stdout_as: stdout_output
  - id: logger
    inputs:
        example_output: example/stdout_output

send_logs_as: Option<String>

Redirect structured log entries to a data output as JSON strings.

Unlike send_stdout_as which sends raw stdout lines, this sends only parsed structured log entries (with level, timestamp, message, fields).

Example

nodes:
  - id: sensor
    path: ./sensor
    send_logs_as: logs
    outputs:
      - data
      - logs

min_log_level: Option<String>

Minimum log level for this node (error, warn, info, debug, trace, stdout).

Logs below this level are suppressed from file output, coordinator forwarding, and send_logs_as routing.

Example

nodes:
  - id: noisy_sensor
    path: ./sensor
    min_log_level: info

max_log_size: Option<String>

Maximum log file size before rotation (e.g. “50MB”, “1GB”).

When the JSONL log file exceeds this size, it is rotated. Old files are renamed with numeric suffixes (.1.jsonl, .2.jsonl, etc.) and the oldest are deleted once 5 rotated files exist.

Example

nodes:
  - id: sensor
    path: ./sensor
    max_log_size: "100MB"

max_rotated_files: Option<u32>

Maximum number of rotated log files to keep (default: 5)

build: Option<String>

Build commands executed during dora build. Each line runs separately.

The build key specifies the command that should be invoked for building the node. The key expects a single- or multi-line string.

Each line is run as a separate command. Spaces are used to separate arguments.

Note that all the environment variables specified in the env field are also applied to the build commands.

Special treatment of pip

Build lines that start with pip or pip3 are treated in a special way: If the --uv argument is passed to the dora build command, all pip/pip3 commands are run through the uv package manager.

Example

nodes:
- id: build-example
  build: cargo build -p receive_data --release
  path: target/release/receive_data
- id: multi-line-example
  build: |
      pip install requirements.txt
      pip install -e some/local/package
  path: package

In the above example, the pip commands will be replaced by uv pip when run through dora build --uv.

git: Option<String>

Git repository URL for downloading nodes.

The git key allows downloading nodes (i.e. their source code) from git repositories. This can be especially useful for distributed dataflows.

When a git key is specified, dora build automatically clones the specified repository (or reuse an existing clone). Then it checks out the specified branch, tag, or rev, or the default branch if none of them are specified. Afterwards it runs the build command if specified.

Note that the git clone directory is set as working directory for both the build command and the specified path.

Example

nodes:
  - id: rust-node
    git: https://github.com/dora-rs/dora.git
    build: cargo build -p rust-dataflow-example-node
    path: target/debug/rust-dataflow-example-node

In the above example, dora build will first clone the specified git repository and then run the specified build inside the local clone directory. When dora run or dora start is invoked, the working directory will be the git clone directory too. So a relative path will start from the clone directory.

hub: Option<String>

Hub package reference (unstable).

References a node published in the Dora Hub index: [<namespace>/]<name>@<semver-requirement>. A bare name is shorthand for the official dora-rs/ namespace.

dora build resolves the reference against the index to a pinned commit and the node is fetched/built through the same machinery as a git node; the package manifest supplies the entrypoint, build command, and typed contracts. Mutually exclusive with path, git, and build.

Example

nodes:
  - id: detector
    hub: dora-yolo@^0.5
    inputs:
      image: camera/image
    outputs:
      - bbox

branch: Option<String>

Git branch to checkout after cloning.

The branch field is only allowed in combination with the git field. It specifies the branch that should be checked out after cloning. Only one of branch, tag, or rev can be specified.

Example

nodes:
  - id: rust-node
    git: https://github.com/dora-rs/dora.git
    branch: some-branch-name

tag: Option<String>

Git tag to checkout after cloning.

The tag field is only allowed in combination with the git field. It specifies the git tag that should be checked out after cloning. Only one of branch, tag, or rev can be specified.

Example

nodes:
  - id: rust-node
    git: https://github.com/dora-rs/dora.git
    tag: v0.1.0

rev: Option<String>

Git revision (e.g. commit hash) to checkout after cloning.

The rev field is only allowed in combination with the git field. It specifies the git revision (e.g. a commit hash) that should be checked out after cloning. Only one of branch, tag, or rev can be specified.

Example

nodes:
  - id: rust-node
    git: https://github.com/dora-rs/dora.git
    rev: 64ab0d7c

restart_policy: RestartPolicy

Whether this node should be restarted on exit or error.

Defaults to RestartPolicy::Never.

shared_memory_pool_size: Option<ByteSize>

Size of the zenoh shared memory pool for zero-copy output publishing.

Accepts an integer (raw bytes) or a string with a unit suffix (KB, MB, GB, case-insensitive). If unset, the DORA_NODE_SHM_POOL_SIZE env var is used, falling back to a built-in default.

Example

nodes:
  - id: camera-node
    shared_memory_pool_size: 128MB

max_restarts: u32

Maximum number of restart attempts. 0 means unlimited.

When combined with restart_window, this limits restarts within the window period. For example, max_restarts: 5 with restart_window: 300 means “5 restarts per 5 minutes”.

restart_delay: Option<f64>

Initial delay in seconds before restarting. Doubles each attempt (exponential backoff).

For example, with restart_delay: 1.0, delays will be 1s, 2s, 4s, 8s, … Use max_restart_delay to cap the backoff.

max_restart_delay: Option<f64>

Maximum delay in seconds for exponential backoff.

Caps the exponentially growing restart_delay. For example, with restart_delay: 1.0 and max_restart_delay: 30.0, delays grow as 1s, 2s, 4s, 8s, 16s, 30s, 30s, …

restart_window: Option<f64>

Time window in seconds for counting restarts.

When set, the restart counter resets after this period of time elapses since the first restart in the current window. This enables “N restarts within M seconds” semantics.

health_check_timeout: Option<f64>

Health check timeout in seconds.

When set, the daemon monitors this node for activity. If the node does not communicate with the daemon within this timeout, it is killed and the restart policy is evaluated.

finish_grace_secs: Option<f64>

Per-node finish-drain grace period in seconds.

Overrides the global DORA_FINISH_DRAIN_GRACE_SECS for this node only. When all other nodes in a dataflow have finished, the daemon waits this long after the node’s last input closes before force-stopping it.

Set to a large value (e.g. 3600.0) for nodes that need significant post-input compute time (ML training, large-batch inference, checkpoint writes) to prevent premature SIGKILL while the computation is in progress.

When unset, the global grace period applies (default 120s, controlled by DORA_FINISH_DRAIN_GRACE_SECS).

module: Option<String>

Path to a module definition file (e.g. nav_module.yml).

A module is a reusable sub-dataflow: a group of nodes with declared inputs and outputs. At build time the module is expanded inline — internal node IDs are prefixed with {module_id}. and all wiring is rewritten so the runtime sees only flat nodes.

Mutually exclusive with path, operators, operator, custom, and ros2.

Example

nodes:
  - id: nav_stack
    module: modules/navigation_module.yml
    inputs:
      goal_pose: localization/goal

params: BTreeMap<String, String>

Parameters passed to a module for compile-time substitution.

Only meaningful when module is set. Values are substituted into inner node args fields (using ${_param.name} syntax) and can be injected into inner node env maps.

Example

nodes:
  - id: nav_stack
    module: modules/navigation_module.yml
    params:
      speed: "2.0"
      mode: turbo

cpu_affinity: Option<Vec<usize>>

CPU cores to pin this node’s process to (Linux only, ignored on other platforms).

Example

nodes:
  - id: fast_node
    path: ./fast_node
    cpu_affinity: [0, 1]

deploy: Option<Deploy>

Unstable machine deployment configuration

Trait Implementations

impl Clone for Node

fn clone(&self) -> Node

Returns a duplicate of the value.

fn clone_from(&mut self, source: &Self)

Performs copy-assignment from source.

impl Debug for Node

fn fmt(&self, f: &mut Formatter<'_>) -> Result

Formats the value using the given formatter.

impl<'de> Deserialize<'de> for Node

fn deserialize<__D>(__deserializer: __D) -> Result<Self, __D::Error>

where __D: Deserializer<'de>,

Deserialize this value from the given Serde deserializer.

impl JsonSchema for Node

fn schema_name() -> Cow<'static, str>

The name of the generated JSON Schema.

fn schema_id() -> Cow<'static, str>

Returns a string that uniquely identifies the schema produced by this type.

fn json_schema(generator: &mut SchemaGenerator) -> Schema

Generates a JSON Schema for this type.

fn inline_schema() -> bool

Whether JSON Schemas generated for this type should be included directly in parent schemas, rather than being re-used where possible using the $ref keyword.

impl Serialize for Node

fn serialize<__S>(&self, __serializer: __S) -> Result<__S::Ok, __S::Error>

where __S: Serializer,

Serialize this value into the given Serde serializer.