Solace Cloud: Managed Event Brokers, Deployment Models and Who Runs What

Solace Cloud is the managed service form of the Solace Event Broker. Solace deploys, patches and operates broker services for you on AWS, Azure and Google Cloud, or inside your own Kubernetes cluster, and you manage them from a web console called Mission Control. Until May 2025 it was called PubSub+ Cloud, and many people still search for it under that name (Solace rename table). The broker inside is the same software Solace sells for self-managed use, so the protocols, topics and queues described elsewhere in this cluster apply unchanged.

This page explains what Solace Cloud is, its three deployment models, who is responsible for what in each, how services are sized, and what to check before you sign. For the company and the rest of the portfolio, start at the Solace hub.

What Solace Cloud is, and what it is not

It is a managed broker service, not a different broker. Solace states feature parity across its cloud, software and appliance form factors (Solace IoT page). An application written against a self-managed broker in a plant can connect to a Solace Cloud service with a change of host name and credentials. That matters for a hybrid design, because the same topic hierarchy can run in a plant and in the cloud.

It is also the home of Solace’s platform services. The same Solace Cloud account gives access to Mission Control for creating and connecting brokers, Solace Insights for monitoring, and the Solace Event Portal for designing and governing events. The docs group Event Portal, Insights and distributed tracing as “platform services” on top of the broker (What is Solace Platform).

It is not a serverless queue. You buy broker services of a given size, called a service class, and you choose where each one runs. That is closer to a managed database than to a pay-per-message cloud queue such as Amazon SQS, and it shapes both cost and design.

Solace’s product page says the service runs as “fully managed AWS, Azure, and GCP deployments, plus support for Oracle, Alibaba, and more”, with Solace handling “deployment, upgrades, patching, and ongoing management” (Solace Cloud page).

Solace Cloud deployment models

Solace documents three ownership models (deployment ownership docs). The docs now call them clusters; earlier pages and the fact sheets we used call them regions.

Model	Who runs the infrastructure	Where it runs	Connectivity	Infrastructure cost
Public	Solace	Solace-controlled shared VPC or VNet on AWS, Azure or Google Cloud	Public internet, secured with TLS	Included in the service price
Dedicated	Solace	Solace-controlled infrastructure reserved for one customer; you may supply CIDR blocks for peering	Public, private regional and private to on-premises	Included in the service price
Customer-controlled	You (the Kubernetes cluster); Solace runs the broker services	Your own Kubernetes: OpenShift, Rancher RKE1 and RKE2, EKS, AKS and ARO, GKE, Alibaba ACK, Huawei CCE and others	Public, private regional and private to on-premises	Yours

Sources: ownership models and comparison.

Public suits applications that already reach the internet and workloads where getting started fast matters more than network isolation. Dedicated is the usual enterprise choice: Solace still runs everything, but the network is yours alone and can be peered into your cloud accounts. Customer-controlled is the model for data that must not leave a facility or a sovereign cloud, and it is the one most relevant to a plant that wants managed brokers on its own hardware.

The Solace Cloud shared responsibility model

A managed service never means you own nothing. Solace’s roles and responsibilities page sets out the split, and the diagram below summarises it.

Three points from the documentation deserve emphasis:

1. Upgrades are shared. Solace upgrades the platform and the Mission Control Agent, but “you must upgrade your event broker service before it reaches End of Support” (roles docs). Since August 2026 customers can schedule their own broker upgrades, which helps a plant align a change with a shutdown window. The release model behind those upgrades is covered on releases and LTS.
2. Application-level configuration is yours. Client usernames, queues and JNDI objects are configured by the customer. A badly sized queue on a managed broker fills up exactly as it would on your own server.
3. Monitoring is split by layer. Solace monitors the infrastructure and the broker services. You monitor your applications, using Insights or your own tools.

Choosing where a Solace Cloud service runs

Every service lives in one cloud region or one Kubernetes cluster. The choice of region is a latency, cost and data residency decision, not an administrative detail.

Latency follows distance. A broker in a cloud region several hundred kilometres from a plant adds round-trip time to every guaranteed message. For dashboards that is irrelevant. For a line that waits on an acknowledgement before releasing the next order, it is not.

Egress is the hidden cost. Cloud providers charge for data leaving a region, and a design that fans plant data out of the cloud to many consumers in other regions or on premises pays that charge repeatedly. The hybrid and multi-cloud page covers the topology choices.

Plants usually keep a local broker. An illustrative scenario: a manufacturer with six plants puts a self-managed or customer-controlled broker at each site, so the line keeps running when the WAN drops, and links those brokers to a Dedicated Solace Cloud service that feeds ERP and analytics. Solace calls this pattern an event mesh; the multi-site edge to cloud page works through it, and our article on OT network segmentation in brownfield plants covers what has to be true of the network first.

Service classes and sizing

Solace Cloud services are bought by service class. The enterprise classes on Solace’s pricing page, as of October 2026:

Service class	Client connections	Throughput	Queues	Default storage
ENT-250	250	450 Mbps	250	50 GB
ENT-1K	1,000	450 Mbps	1,000	200 GB
ENT-5K	5,000	750 Mbps	5,000	400 GB
ENT-10K	10,000	750 Mbps	10,000	600 GB
ENT-50K	50,000	1,000 Mbps	50,000	800 GB
ENT-100K	100,000	1,000 Mbps	100,000	1,000 GB

In August 2026 Solace added an Enterprise 200K class with 200,000 connections per broker, enabled through the account team. Storage is configurable up to 6 TB, and services are highly available by default with a standalone option for non-production use.

Size on connections and spool, not only on throughput. A plant estate with thousands of MQTT devices can exhaust a connection limit long before it approaches 450 Mbps. A consumer that goes offline for a weekend can fill the message spool. Both are cheaper to plan for than to discover.

Solace Cloud packages and pricing

Solace publishes no dollar prices. The pricing page lists three packages: Foundation (Event Portal Designer and Catalog, Event Broker Manager, dedicated or customer private clusters), Accelerate (adds Mesh Manager Link Builder and Event Portal discovery, audit and self-service) and Scale (adds Solace Insights, distributed tracing, Schema Registry and Event Portal API management). Licensing is a fixed subscription or consumption drawdown measured in Platform Capacity Units, and a 30-day trial is advertised. The full breakdown, with a budgeting checklist, is on Solace editions and pricing.

Security and compliance in Solace Cloud

Solace states the following for Solace Cloud as of October 2026 (security page; compliance docs):

• SOC 2 Type 2 (security, availability, confidentiality, processing integrity), report through the account team
• ISO/IEC 27001:2022, with the Statement of Applicability on request
• CSA STAR Level 1, a HIPAA business associate agreement on request, and GDPR compliance
• Encryption at rest through the cloud provider’s key management, revocable API keys and network isolation in Dedicated and customer-controlled clusters

FedRAMP is not claimed anywhere we found. A US federal or defence-adjacent manufacturer should ask directly rather than assume. Broker-level security (Message VPNs, ACLs, OAuth) is covered on Message VPNs and security.

Limits and open questions

• No public pricing. Every number that matters for a business case comes from a quote. The service class table tells you capacity, not cost.
• No permanent free tier advertised. Only a 30-day trial appears on the pricing page as of October 2026. Development environments therefore cost money or run on the self-managed Standard Edition, which Solace’s docs mark “not production deployable” (software broker editions).
• Customer-controlled is not “fully managed”. You own cluster health, storage and networking. If your plant has no Kubernetes skills, that model moves work onto your team rather than off it.
• Feature availability can differ by form factor in practice. Solace claims parity, but its own docs list Kafka bridging for software brokers only. Check any feature you depend on against the cloud documentation.
• Region list. Solace names AWS, Azure and Google Cloud, plus Oracle and Alibaba support; confirm that the specific region you need is available for the service class you want.
• Exit path. The broker is the same software you can run yourself, which is a real mitigation, but Event Portal designs and Insights dashboards live in Solace’s cloud. Ask how you would export them.

How to evaluate Solace Cloud

• Which deployment model fits each environment (development, test, production, plant edge), and why?
• Which service class does each production service need, sized on connections, spool and throughput separately?
• Which cloud regions are available for that class, and where are the main producers and consumers?
• What egress charges does the topology create, and who pays them?
• How are upgrades scheduled, and how much notice do we get before a version reaches end of support?
• How is disaster recovery between regions configured, and what does it add to the quote?
• Which compliance reports can we see before signing, and does anything we need (for example FedRAMP) fall outside them?
• If we leave, how do we export broker configuration, Event Portal designs and monitoring?

If those answers feed a wider decision about where your plant data should live, that is the scope of a modernization roadmap. For the integration work itself, see IT/OT integration.

Deeper

• Solace Mission Control: the console for creating, upgrading and connecting broker services, and the agent that runs inside your cluster
• Solace Insights and observability: dashboards, monitors, OpenTelemetry tracing and what to watch on a broker

Back to the Solace hub, or across to Solace Event Portal, the design and governance tool that shares the same Solace Cloud account.