Solace Edge to Cloud: Multi-Site Plants, Intermittent WAN and DMZ Placement

A Solace edge to cloud design connects many plants to one enterprise and cloud layer through brokers that keep working when the WAN does not. The pattern Solace itself recommends, in a June 2026 blog on broker placement, is a broker at the edge that “holds events locally when the link is down and forwards them losslessly once it returns”, with “edge brokers [as] nodes of one event mesh”. This page turns that into a design: where each broker sits, which layer buffers what, how the DMZ fits, and what drives residency and cost. It is written for the plant or IT/OT lead who has to make it survive a Tuesday-night fibre cut.

It sits under Solace in manufacturing in the Solace cluster.

The Solace edge to cloud topology

Where the brokers live

Solace’s placement blog gives the rule in plain terms: put a broker locally “in the plant, on the factory floor, or at a remote facility” when decisions need fast responses or data must survive a connectivity interruption, and consider cloud placement for a “small site with a few devices, forgiving latency, and a dependable link”. We agree, and add one test: if the plant must keep producing during a WAN outage, it needs a broker it can reach without the WAN.

Placement	Fits	Watch
Plant broker only, direct to cloud	Small sites, latency-tolerant data, good links	Plant systems lose the UNS when the link drops
Plant broker plus DMZ node, then enterprise and cloud	Most regulated or multi-site manufacturers	More brokers to license, patch and monitor
DMZ node only, plant systems publish across the firewall	Sites with very few publishers	OT clients cross the firewall for every message
Solace Cloud Customer-Controlled Region on site Kubernetes	Teams that run Kubernetes at the plant	Kubernetes skills at the site, and the cluster becomes a plant dependency

Store-and-forward across an intermittent WAN

Only guaranteed messages are buffered. Solace has two delivery modes. Direct messages are at-most-once and low latency; guaranteed messages are spooled to endpoints and acknowledged. Anything that must survive an outage, such as a production confirmation, a quality hold or a batch record, has to be published as guaranteed and attracted to a queue. The guaranteed messaging page explains the mechanics.

Four buffers, in order.

1. Edge publisher. Ignition’s MQTT Transmission and HighByte Intelligence Hub both document local store-and-forward (see Ignition and HighByte).
2. Plant broker queues. Spooled messages wait for their consumers.
3. The link between sites. Dynamic message routing propagates subscriptions and forwards messages between clusters. A Message VPN bridge is the static alternative, and for guaranteed messages it uses a durable bridge queue on the remote Message VPN.
4. Central queues. One per consuming application, so ERP being down for maintenance does not stop the data platform.

Size the spool for the outage you plan for (illustrative). A site publishing 2,000 guaranteed events a second at 1,000 bytes each produces about 7.2 GB an hour, or 57.6 GB over an eight-hour outage. Solace’s edition table gives a maximum spool of 800 GB for the Standard Edition and 6 TB for Enterprise, but the disk you provision and the quota you configure are the limits that apply. And remember the Standard Edition is documented as not production deployable.

Test the recovery, not just the outage. When the link returns, the backlog and live traffic compete for the same bandwidth. Decide whether live data or the backlog goes first, and time how long a full flush takes on the real link. A plant on a 20 Mbps link that has queued 57.6 GB needs more than six hours of full bandwidth to clear it, before any live traffic, which can be longer than the outage itself.

DMZ placement

ISA-95 and the Purdue-style models plants use put an IT/OT DMZ between site operations (Level 3) and the enterprise (Level 4). The broker design should follow the zones and conduits, not cut across them:

• Plant broker inside Level 3. It serves the site and is reachable without the DMZ.
• A broker node or bridge endpoint in the DMZ. It is the only messaging component both sides talk to, and it can hold a queue for the WAN.
• No enterprise or cloud client connects directly into Level 3.

Two documented details shape the DMZ design. First, the DMR overview states that “messages only propagate between directly-connected clusters”. If you planned a relay through a DMZ broker from plant to cloud, confirm with Solace how traffic crosses it, for example with a Message VPN bridge. Second, decide which side opens each connection: firewall rules depend on it, and most OT security teams will only allow connections initiated from the more trusted zone outward. Our post on OT network segmentation in brownfield plants covers the zone-and-conduit work underneath this, and the Message VPNs and security page covers tenant separation on the broker itself.

Data residency and cost

Decide what leaves the plant per topic. Raw high-frequency data usually stays in the site UNS and historian; aggregates and events travel. That single decision drives WAN usage, cloud egress, broker sizing and most residency questions.

Cloud ownership models change who pays for what. Solace Cloud offers three models: Public Regions, Dedicated Regions and Customer-Controlled Regions on your own Kubernetes. Infrastructure cost is included in the service price for the first two and is yours for the third. Which region you choose decides where data rests. The hybrid and multi-cloud page covers the cloud side.

The cost drivers to price: number of brokers (plant, DMZ, central, cloud), HA at each tier, spool storage, WAN and egress, and the people to run it. Solace publishes no dollar prices, so get a quotation for your site count early.

Where it gets hard

• Direct messages vanish in an outage. Audit which flows are published as direct and whether any of them matter.
• Mesh topology is not automatic transit. Per the DMR documentation, messages only cross between directly connected clusters. Draw every link.
• Will messages are not sent on broker failover, per the MQTT documentation. Plant-side MQTT and Sparkplug clients need another way to detect stale data (see Solace Sparkplug).
• Backlog floods. A large backlog arriving at once can overwhelm a consumer that has never seen it. Rate-limit or test.
• Operations at many sites. Brokers at every plant need patching on the LTS cadence (10.26.0 is the current long-term release as of October 2026), monitoring and an owner.

If the zones and conduits at your sites are not documented yet, that comes first: an OT network assessment maps them and tells you where each broker can legitimately sit. For the namespace that travels across this topology, see the unified namespace page.