Running the edge server from the editor
The configurator can start the edge server on the configuration you are editing, the way Node-RED deploys a flow or TIA Portal runs a station. A bar at the bottom of the studio shows the state of that instance, its endpoint url, and the runtime's log.
This exists because the studio's Virtual address space panel is a
simulation: it instantiates instances: and nothing else. Brownfield
bindings, jsonata value: expressions, on-demand evaluation and replicated
subtrees are invisible in it. Only a real run shows those — and the runtime's
log is where it reports which mapping resolved and which did not.
Deploy is a command, not a file change
The runtime is started with run --managed, which installs no file
watcher. Its lifecycle is driven by explicit commands over the IPC channel
between the editor and the runtime process.
That is deliberate. Detecting a configuration change by watching the file is unreliable in exactly the deployment everyone uses: on a Docker Desktop bind mount a write from the host raises no filesystem event inside the container, so the runtime would never notice. Watching also cannot report anything — the editor would write the file and never learn whether the new configuration actually loaded.
With commands, every deploy is acknowledged. A configuration that fails to
load reports why (cannot find nodeset file models/foo.xml …), and a
successful one reports the endpoint url plus a digest of the configuration
that was loaded, shown as #a1b2c3d4e5f6 next to the state. If that digest
changes after a redeploy, your revision is definitely the one running.
The buttons act on the saved file. Save before deploying — the bar warns you when the buffer differs from what is on disk.
Controls
| Button | Effect |
|---|---|
| Run | starts the edge server from the saved configuration |
| Redeploy | the runtime re-reads the configuration and restarts |
| Stop | stops the edge server and releases its port |
Configuration
| Environment variable | Meaning |
|---|---|
OMNI_EDGE_CLI | path to the edge CLI (dist/opcua-omni-edge.js). Set this when the runtime is not installed as a dependency of the editor. When unset, the editor resolves the opcua-omni-edge package, then falls back to a sibling package in a development checkout. |
DISABLE_RUNTIME_CONTROL | set to true to remove the feature: the bar disappears and the /api/runtime/* endpoints answer 403. |
Starting the edge server opens real connections to the devices declared in
brownfieldDevices: and binds the OPC UA port from port:. On a plant
network that is not a neutral act — an accidental deploy can disturb
production, or collide with an already running instance on the same port.
Set DISABLE_RUNTIME_CONTROL=true on any editor instance that must never do
this.
Where custom models are looked up
The runtime resolves imports[].filename relative to the folder holding
the configuration file, which is the same folder the editor stores uploaded
models in. A model imported through the studio is therefore found by the
runtime with no further configuration: /data/config.yaml plus
models/my.NodeSet2.xml resolves to /data/models/my.NodeSet2.xml on both
sides.
Without the editor
The same mechanism is available from the command line:
# controller-driven: no watcher, commands over IPC (what the editor uses)
opcua-omni-edge run --managed -c config.yml
# unattended: reload when the file changes
opcua-omni-edge run --watch -c config.yml
# unattended on a bind mount, where filesystem events never arrive:
# compares modification time AND content instead
opcua-omni-edge run --watch --poll -c config.yml
--managed requires an IPC channel, so it only works when the process is
started with child_process.fork().