Device Shadow

Every edge deployment has a device shadow — a cloud-side data structure that tracks the configuration state of the edge gateway. The shadow acts as an intermediary between the cloud platform (which defines what the configuration should be) and the edge gateway (which reports what it has actually applied).

Shadow state model

The shadow consists of three sections:

Desired state

The desired state is managed by the cloud platform. It represents the configuration that should be running on the edge gateway. When you publish a configuration, the platform updates the desired state.

Reported state

The reported state is managed by the edge gateway. The Fleetera Edge Runtime updates it after applying a configuration.

Delta

The delta is computed automatically by comparing the desired and reported states.

How synchronization works

The Edge Runtime on the gateway polls the cloud every 30 seconds. When it detects that the desired config version is higher than the reported version, it starts the synchronization process:

1. Poll — the runtime fetches the shadow and compares versions
2. Mark applying — the runtime notifies the cloud that it is applying the configuration
3. Apply — the runtime diffs the desired connectors and bindings against what it is running, then adds, removes, or reconfigures its in-process protocol drivers accordingly
4. Cache — the applied configuration is written to local disk, so the gateway can restart with its known-good configuration even while the cloud is unreachable
5. Report — the runtime reports the applied config version back to the cloud

If the application succeeds, the reported config version is updated to match the desired version, and the sync status becomes In Sync.

What the configuration contains

The desired configuration is the full picture of what the gateway should acquire:

• Connectors — one entry per connector in the gateway's scope, with the protocol (OPC UA, Modbus, MQTT, or REST), endpoint address, and protocol-specific settings such as security policy and authentication
• Bindings — for each connector, the list of bound variables with their protocol addresses (for example, OPC UA node IDs or Modbus registers) and sampling configuration
• Runtime settings — deployment-level settings such as the store-and-forward buffer sizing

Discovery utility

OPC UA address space discovery is performed by the Edge Crawler utility container that ships alongside the runtime. Discovery is only available when:

1. A deployment exists for the site
2. The deployment status is Online (the gateway has reported a heartbeat)
3. The crawler utility is enabled on the deployment

Toggling the crawler utility is a configuration change like any other — flipping it regenerates the deployment's compose file. The connector's Data Model tab surfaces a readiness banner that walks you through any missing prerequisite and offers a one-click Enable Discovery Utility action.

The Edge Runtime's role

The Fleetera Edge Runtime handles the edge side of the shadow pattern itself — there is no separate sync agent:

• Configuration polling — checks for changes every 30 seconds, and immediately when the cloud requests it
• Configuration application — applies connector and binding changes to its built-in protocol drivers without restarting
• Local caching — persists the applied configuration so a gateway restart during a cloud outage comes back with the last known-good configuration
• Heartbeats — sends a heartbeat to the cloud every 60 seconds with driver, buffer, and host health
• Idempotent updates — re-applying the same configuration is safe