Runners overview
A Runner is a deployed container that executes one or more node templates by claiming tasks. When a node in a session is ready, HEAT hands the work to a runner of the right type, the runner reads the parent outputs, does its job and stores a new node output.
You do not call a runner. You put its node templates in a session template and the platform does the rest. A runner is not a node template. One runner image typically implements many node templates, and a node template name is the long-lived contract you author against.
The five platform runners
| Runner | Feature | Container image | Node templates | Hub |
|---|---|---|---|---|
| core-utils | core-utils (Core Utils) | runner-core-utils | 31 general transforms for CSV, JSON and capture protobuf, plus entity-state analytics and tabular-to-dataservice | core-utils |
| dashboard-tools | dashboard-tools (Dashboard Tools) | runner-dashboard-utils | 12 templates that filter JSON and publish dashboards, including dashboard-v2 and heat-dataservice-merge | dashboard-tools |
| system-utils | heat-core (HEAT System Nodes) | None. Hosted inside the Core API | 19 platform-only templates, including input-node, system-arbex-js, system-protobuf-extract, capture-discovery and heat-system-next-dimension | system-utils |
| audio-utils | audio-utils (Audio Utils) | runner-audio-utils | 4 templates for PCM conversion, audio metrics, transcripts and voice analysis | audio-utils |
| video-utils | video-utils (Video Utils) | runner-video-utils | 2 templates for chunked adaptive video and video atlas encoding | video-utils |
system-utils is the platform’s built-in runner, hosted inside the Core API. It is always present and cannot be switched off, so templates built only from its node templates run on every install. The other four are versioned images that an operator registers and enables. Authoring principles explains why platform templates prefer system-utils first.
The dashboard-tools runner is the one whose names differ. Its feature is dashboard-tools, its runner type and image are named dashboard-utils, and its documentation calls it dashboard-tools.
How runners are enabled
Each runner ships with a manifest.heat file that registers a Feature: the runner type with its image, CPU and memory limits, and the node templates it implements with their configuration schemas. An operator uploads the manifest, and the feature appears on the Control Centre Features page with a switch.
A session template can only be imported when every node template it names belongs to a registered feature that is switched on. When a feature is switched off, its node templates stay registered but no new work is scheduled to its runner.
Runners scale with demand. The platform starts a runner container when tasks of its type are pending and lets it stop when none remain. Resource limits come from the manifest.
Project companion runners
Projects often ship their own runner alongside the platform ones. A companion runner is built the same way: a container image, a manifest.heat that registers a feature and its node templates, and the same task-claiming runtime. Its node templates appear in the catalog of the environment it is registered on and can be mixed with platform node templates in one session template. Companion runners are documented with their projects, not here.
Related
- Building your own runner
- Node template catalog
- Runner concept, including tasks
- Features in the Control Centre