Solace Hybrid Cloud: Running One Event Mesh On-Premises and in Cloud

A Solace hybrid cloud deployment is one event mesh that spans your own plants and data centres and one or more public clouds. Brokers run where the applications are: self-managed software or appliances on premises, Solace Cloud services in AWS, Azure or Google Cloud, or Solace-managed brokers inside your own Kubernetes. Dynamic Message Routing links them, so a plant publishes once to its local broker and a cloud consumer subscribes to its local broker, with the mesh carrying only the events someone asked for. This page covers the ownership models, how to think about latency, egress and data residency, and what to check before building one.

It belongs to the event mesh overview in the Solace cluster.

The places a Solace broker can run

Self-managed software runs, per Solace’s software page, on VMware, KVM, Hyper-V and Docker, on AWS, Azure, GCP and OpenStack, and on Kubernetes and OpenShift. Appliances sit in data centres or at the edge. Solace Cloud offers, in Solace’s words, “fully managed AWS, Azure, and GCP deployments, plus support for Oracle, Alibaba, and more”. Solace claims feature parity across the three form factors, which is what makes a mixed mesh workable: a topic, a queue or an ACL means the same thing in every location. The trade-offs between form factors are on software vs appliance.

Solace hybrid cloud ownership models

Solace Cloud has three ownership models, set out in the deployment documentation. Self-managed brokers make a fourth option. The question each answers is: who runs the broker, and whose infrastructure is it on?

Model	Who runs the broker	Whose infrastructure	Connectivity	Infrastructure cost
Self-managed (software or appliance)	You	Yours, on premises or in your cloud account	Whatever you build	Yours
Solace Cloud, Customer-Controlled	Solace Cloud manages the deployments; you own cluster health	Your Kubernetes: OpenShift, Rancher, EKS, AKS or ARO, GKE, Alibaba ACK, Huawei CCE and more	Public, private regional and private on-premises	Yours
Solace Cloud, Dedicated	Solace	Kubernetes owned by Solace and dedicated to you	Public, private regional and private on-premises	In the service price
Solace Cloud, Public	Solace	Shared cloud networks Solace controls; brokers still dedicated to you	Public internet only, secured	In the service price

Source: Solace deployment documentation and the options comparison, as of October 2026. In the Dedicated model, a Mission Control Agent creates a secure connection back to Solace’s control plane and relays commands; the Mission Control page covers that layer.

For a plant, Customer-Controlled is the interesting row. It puts a Solace-managed broker on infrastructure you own, which can be inside the site, while Solace Cloud handles deployment and upgrades. Whether your OT security policy accepts a vendor control plane reaching into a plant cluster is a question for your security team, not for the vendor.

Solace hybrid cloud latency: put the broker next to the work

A mesh does not make the network faster. An event from a plant in Ontario to a consumer in a European cloud region still crosses the Atlantic. What the mesh changes is where clients connect. Each application talks to a broker in its own site or region, so publish and subscribe calls stay local and fast, and only the broker-to-broker hop pays the long-distance latency.

The plant consequence is control-loop independence. Anything that reacts within a shift, such as a line stop, a quality hold or an andon, should have its consumer on the plant broker, not in the cloud. The cloud receives the same event for analytics and planning. Solace’s June 2026 article on where brokers should live makes the same argument: “The center of gravity of industrial data is not the cloud, but the factory floor.”

Egress: pay for one copy, not one per consumer

Public clouds charge for data leaving their networks, at rates set by each provider. Two DMR properties work in your favour. First, an event crosses a link only when someone on the far side subscribed to it. Second, only one copy crosses each link, however many subscribers wait on the other side. A plant stream consumed by ten cloud applications costs one copy over the WAN, not ten.

Two habits undo the saving:

1. Broad wildcards in the cloud. A data team subscribing to > “to see everything” pulls every event from every site through every egress point. Agree narrow subscriptions, and enforce them with ACLs.
2. Cloud-to-cloud ping-pong. If a consumer in Azure needs an event published in AWS, it crosses a provider boundary every time. Place consumers in the cloud where their data originates when you can.

Data residency and sovereignty

Routing by subscription is also routing by policy. If no broker outside a country holds a subscription to that country’s personnel or quality events, those events never leave. That is a useful property, but it is a technical one: it holds only as long as nobody adds a subscription. Three controls make it durable:

• Topic design with a region or site level, so that policy can be written as a topic pattern. See topics and wildcards.
• ACL profiles that refuse subscriptions to restricted patterns from clients outside the region. See Message VPNs and security.
• Customer-Controlled or self-managed brokers for data that must stay on your own infrastructure.

Disaster recovery replication is a separate data flow. Replication copies a Message VPN’s Guaranteed messages to a standby site, and Solace documents that it can be synchronous or asynchronous per topic. A DR site in another jurisdiction is a residency decision in its own right. See high availability and disaster recovery.

Linking cloud services and self-managed brokers

In Solace Cloud, Mesh Manager builds the links between Enterprise event broker services. It has connectivity rules that shape a hybrid design: a service with a private endpoint can connect to a service with a public endpoint “provided that the initiator is the service with the private endpoint”, and private-to-private links need IP connectivity between the regions. Self-managed plant brokers are linked by configuration.

Solace’s published hybrid references include Indiana Farm Bureau Insurance, which Solace describes as running a hybrid cloud event mesh, and the FAA, which extended its partnership in 2026 with Enhanced SWIM Cloud Services. Neither is a plant, and we have no independent detail on either.

Where it gets hard

• Two operating models in one mesh. Solace Cloud services upgrade on a schedule you set through self-serve upgrades (added August 2026); self-managed brokers upgrade when your team does it. Keep versions within the supported range on both sides, and track the LTS line (10.26.0, supported to June 2028, as of October 2026). See releases and LTS.
• Firewall direction. Plants rarely accept inbound connections from a cloud. Design links so the plant side initiates, and confirm that each link type supports it.
• Kafka in one cloud, mesh in another. Solace documents in-broker Kafka bridging for software brokers; check the path if the Kafka feed must come from a cloud service. See Kafka integration.
• Pricing. Solace publishes no list prices. Cloud services are bought through sales or the AWS, Azure and Google Cloud marketplaces, and cloud egress is billed separately by each provider. Ask for both in one model. See editions and pricing.

Next, see how DMR forwards events in dynamic message routing, or how this plays out across many plants in multi-site edge to cloud. If the question is the order to move plants and systems into this shape, that is a modernization roadmap conversation.