Managing multiple nodes
This article refers to Platform v3.4.0. The current Platform version is v3.3.0.
Overview
Operating a fleet means applying the same change to many Edge Nodes: deploying an application, updating a version, pushing a new network configuration. Barbara covers that with batches, which apply one command to a set of nodes in a single operation.
Most real fleets, however, are not configured identically. A gateway address, a plant identifier, or an MQTT host is different on each node, and an operation that can only send one value per parameter stops being useful at exactly the point where doing it by hand stops being practical. Barbara addresses this with two further pieces: hypervariable sets, which hold a value per node, and the config repository, which stores the JSON documents you reuse across nodes and workloads.
This article introduces the three and how they fit together. Each has its own reference article, linked at the end.
The three building blocks
| Piece | What it is | What it answers |
|---|---|---|
| Batch | One command applied to many nodes in a single operation | What am I doing, and to which nodes? |
| Hypervariable set | A table of values, one row per node, scoped to a group | Which value does each node get? |
| Config | A reusable JSON configuration document, stored in a repository | What configuration am I applying? |
They are independent. A batch works perfectly well without hypervariables when every node takes the same value, and a config is useful on a single node with no batch involved. They become interesting in combination: a config that contains hypervariable references, applied through a batch, delivers a different configuration to every node in one operation.
Batches
A batch is an operation, not a stored setting. You choose the command, the target nodes, the parameters, and dispatch it. The wizard has five steps, and the last one validates the batch against every target node before anything is sent, so a node that cannot run the command is visible beforehand.
Once sent, a batch reports back: each node acknowledges the command, and the Batches view aggregates those acknowledgements so you can tell success from silence.
Hypervariable sets
A hypervariable set belongs to a group and behaves like a spreadsheet: one row per node, one column per variable, one value per cell. You manage it as a CSV, downloading a template, filling it in, and uploading it.
In a batch, a parameter can reference a variable instead of holding a literal value. At launch, Barbara substitutes each node's own value.
Configs
A config is a JSON document held in a central repository rather than edited in place on each workload. Each one records its type, the application it belongs to, and how many nodes it is applied on, so a configuration you wrote once is visible, searchable, and reusable.
A config can contain hypervariable references, which is what makes one document serve a whole fleet.
How they work together
The order matters, because each piece depends on the one before it:
- Define the values that differ. Create a hypervariable set for the group and fill in the CSV, one row per node.
- Write the configuration once. Create a config whose varying parameters are hypervariable references rather than fixed values.
- Apply it as a batch. Select the command and the target nodes, select the set, and point the parameters at their variables.
- Validate before launching. The last wizard step resolves every reference against every node and reports which ones are ready.
- Follow the result. The Batches view reports what each node did with the command.
Steps 1 and 2 are done once and reused. Step 3 onwards is what you repeat.
What varies per node
It helps to know in advance which parameters are worth turning into hypervariables. In practice these are the values tied to where a node physically is or what it is connected to:
- Network addressing: the node's own address, its gateway, its subnet mask.
- Identifiers: a serial number, a machine or plant identifier, a sensor reference.
- Connection endpoints: an MQTT host, a database URI, an API endpoint per site.
Everything else, the values that are genuinely the same across the fleet, stays as a fixed value. The point of separating them is that the fixed part is written once and only the varying part needs a table.
What to know before you start
Four constraints shape how you plan this, and all four are easier to accommodate up front than to work around later.
- Hypervariables are scoped to a group. Every target node of a batch that uses them must belong to the same group. A node that changes group loses its alignment with the set.
- Uploading a set replaces it entirely. A CSV upload is a full overwrite, not a merge, so always start from a fresh download rather than an older copy of the file.
- Configs with hypervariable references only work in batches. On a single node, Barbara has no group context to resolve them against, so such a config is offered but not selectable.
- Names are hard to change later. A variable name lives inside every reference that uses it, so agree on a convention before the first upload.
A batch is a high-impact operation: one action affects every target node, and most commands cannot be undone. Use the validation step as a real review rather than a formality, and consider running a new batch against a small group of nodes first.
Whether access to hypervariables depends on a company tier still needs confirmation, and the screenshots for this article are pending.
Where to start
- Batch operations — the Batches view, the five-step wizard, and tracking a sent batch.
- Config repository — store and reuse the JSON configurations you apply.
- Hypervariables — create and maintain a set through its CSV.
- Using hypervariables in batches — reference variables from batch parameters and App Config.
- Batch — Workloads — deploy, update, and reconfigure applications across the fleet.
The remaining articles in this section cover one batch command category each.
Summary
Fleet configuration in Barbara separates three concerns: the operation, the values that differ per node, and the configuration document itself. Batches carry the operation, hypervariable sets hold the per-node values, and the config repository keeps the JSON you reuse.
Keeping them apart is what lets a single operation configure a fleet whose nodes are all different, from one console and without touching a node individually. Start with a batch on a few nodes to see the wizard end to end, then introduce a hypervariable set once you hit a parameter that cannot be the same everywhere.