Boomi vs MuleSoft vs Workato vs Celigo: iPaaS platform comparison

‍

Four platforms show up on almost every iPaaS shortlist I see, and the evaluation usually runs the same way. Someone builds a feature matrix, counts connectors, scores each vendor out of five, and the highest total wins. Six months later the team hits a wall that was documented publicly on day one.

This choice is decided by three technical facts: where the runtime executes, where the payload data physically travels, and what the licensing meter counts. None of them shows up on a connector count.

When you get these three right, the remaining feature differences are manageable problems, while getting them wrong leaves you with a platform that no amount of connector coverage can rescue. What follows is built from vendor documentation, published platform limits, and legal SLA text rather than positioning pages.

‍

How Boomi, MuleSoft, Workato and Celigo differ architecturally

These four are not four versions of the same product. They split cleanly into two hybrid-runtime platforms and two cloud-only multi-tenant SaaS platforms, and that split governs almost everything downstream.

Boomi and MuleSoft both give you a real execution runtime you can install and operate yourself, whereas Workato and Celigo do not. Their on-premise agents open a tunnel to systems behind your firewall, and the integration logic still runs in the vendor's cloud.

‍

‍

Runtime and execution architecture: where your integration code actually runs

Boomi Atoms, runtime clusters and Atom Cloud

Boomi's runtime is a Java application you install where you need it. Its documentation defines three shapes: a basic runtime as a single-tenant, single-node engine, a runtime cluster (formerly the Molecule) as a single-tenant, multi-node engine, and a Cloud as a multi-tenant, multi-node engine.

Clustering carries real infrastructure obligations. A runtime cluster requires a shared file system with working file locking, using SMB or CIFS on Windows and NFS on Linux.

Nodes communicate over multicast UDP on port 45588, or unicast TCP on port 7800 where multicast is unavailable. Boomi's requirements list Java 8 JRE or Java 11 JDK, and it bundles Amazon Corretto.

The platform identifies four saturation signals: CPU usage, thread execution count, JVM heap usage, and queue depth. A single slow connector holds a thread, and unrelated processes queue behind it. Forked execution puts each process in its own JVM and contains the damage, at the cost of memory overhead.

Mule 4 runtime, CloudHub 2.0 and Runtime Fabric

Mule 4 has the most modern execution engine of the four. It is reactive and non-blocking, with work assigned to runtime-managed thread pools rather than one thread per request. Those pools are CPU_LITE for sub-10ms non-blocking tasks, CPU_INTENSIVE for heavier transformation, and BLOCKING_IO for I/O-bound operations. From version 4.3 onward the runtime unified these into a self-tuning pool, which removed most of the manual thread tuning that Mule 3 demanded.

You then choose a deployment target, and each has published constraints worth reading before you commit.

CloudHub 2.0 replaced VM-style workers with containerised replicas. It adds fractional vCore sizing, clustering across replicas, Private Spaces with outbound firewall control, and auto-scaling private ingress.

Two limitations matter architecturally, since CloudHub 2.0 does not support persistent queues, which moves durable buffering to Anypoint MQ, and its private endpoints do not support mutual TLS.

Runtime Fabric is the option platform engineering teams should look at first. It runs on customer-managed Kubernetes across EKS, AKS, GKE, OpenShift and Rancher, isolates each application in its own Mule runtime, and allows deployments as small as 0.02 vCore against CloudHub's 0.1 minimum. You own the cluster, MuleSoft owns the runtime and agent. For teams already running Kubernetes with established observability and GitOps, this is the cheapest path to density.

One entitlement detail catches people mid-migration: CloudHub 1.0 and CloudHub 2.0 draw from the same vCore, network connection and private cloud quotas.

Workato and Celigo execute in the vendor cloud

Workato is multi-tenant SaaS on AWS. Its On-Prem Agent opens an outbound TLS WebSocket tunnel to Workato, requires no inbound firewall ports, and can be grouped for high availability and load balancing. The agent provides access to databases, file systems and internal applications, while recipe logic executes in Workato's cloud.

That distinction matters, because if your control requirement is that payload data never leaves your infrastructure, an agent does not satisfy it.

Workato offers Virtual Private Workato for customers who need isolation. Its documentation describes a dedicated environment hosted in its own AWS VPC, connected to customer networks through VPC peering and transit gateway, separate from the commercial cloud. AWS PrivateLink is available on specific plans.

One operational trap in any Workato deployment: SSL inspection appliances such as Zscaler, Cisco Umbrella and Cato break the agent's mutual TLS trust chain. Workato's gateway domains need a bypass rule, and discovering this during go-live week is avoidable.

Celigo runs in an Amazon VPC and uses S3 to temporarily store customer data in transit. Every connection is backed by its own FIFO queue, and concurrency is configured per connection with a maximum that varies by edition.

Connections can borrow concurrency from one another, and Celigo documents no practical limit on the number of connected applications or flows in an account, which is a genuine strength for fan-out heavy estates.

‍

Data residency, certifications and where payload data travels

Boomi local runtimes and MuleSoft Runtime Fabric or standalone deployments can process payload data entirely inside your own infrastructure. The vendor cloud acts as a control plane for design, deployment and monitoring, so your regulated records stay where your compliance owner can point to them on a network diagram.

Workato and Celigo process payload data in the vendor's cloud. Celigo temporarily stores it in S3. Workato retains a job transaction log with a default retention of 30 days, encrypted at rest with AES-256, and job replay depends on that stored trigger data.

Workato's regional footprint is strong for a cloud-only platform. Its documentation lists data centres in the US, EU (Frankfurt), UK, Japan, Singapore, Australia, Israel, South Korea and China, with no cross-region data transfer.

‍

On certifications, Workato publishes SOC 1, SOC 2 and SOC 3 Type II, HIPAA with a BAA, PCI-DSS v4.0.1 Level 1, IRAP at PROTECTED, NIST 800-171A r2, plus ISO 27001, ISO 27701 and ISO/IEC 42001 for AI management, certified in March 2026.

For US federal work the picture is simpler. MuleSoft Government Cloud holds FedRAMP authorisation at the Moderate impact level, granted in August 2019, and MuleSoft announced passing 40 agency authorisations to operate in February 2022. The FedRAMP Marketplace currently lists it as authorised with 71 authorisations and reuses. None of Boomi, Workato or Celigo offers an equivalent FedRAMP-authorised environment.

‍

Development model, transformation languages and skills cost

DataWeave 2.0 and the MuleSoft skills burden

DataWeave 2.0 is the most capable transformation language among the four. It handles more than 20 formats, supports streaming, and expresses complex mappings in a fraction of the surface area a visual mapper would need.

It is also a functional programming language, and that is where MuleSoft implementations fail.

Tooling adds a second decision. Anypoint Studio is the mature Eclipse-based IDE with the better visual DataWeave preview and flow diagrams, while Anypoint Code Builder is the VS Code-based successor, generally available since 2023, Git-native and AI-assisted, and still catching up on MUnit test configuration and visual debugging.

Boomi's visual canvas and scripting escape hatches

Boomi's process canvas with shapes, the Map shape and data process shapes reaches a working integration faster than DataWeave for straightforward mappings, and Groovy and JavaScript cover the cases the canvas cannot express. Add-on modules extend the platform into master data management through DataHub and low-code applications through Flow.

Complex conditional logic is where the visual model strains. A process that would be 30 lines of DataWeave becomes a canvas that is difficult to review in a pull request.

Workato recipes and Celigo flows

Workato builds on recipes, meaning a trigger and a sequence of actions bound together with data pills, its formula language, callable recipes and lookup tables. Its documentation confirms that a version is created every time a recipe is saved and any previous version can be restored, which is the practical safety net business-led building needs. RecipeOps lets recipes monitor other recipes, and separate environments support a dev, test and production lifecycle.

Celigo pairs flows with handlebars templating and five JavaScript hook points: pre-save, post-map, post-submit, post-response and post-aggregate. Integration Apps ship as vendor-managed prebuilt content, and DIY flows cover everything else. For a NetSuite or Shopify estate, that prebuilt content is the reason to choose Celigo, and away from those systems it becomes the reason to look elsewhere.

‍

API management depth: full lifecycle versus endpoint exposure

Two of these platforms genuinely manage APIs while the other two simply expose them, and treating those as equivalent is the most common error I see in iPaaS evaluations.

MuleSoft pairs API Manager as a control plane with the Envoy-based Omni Gateway, formerly Flex Gateway, which enforces policies against APIs running in any environment, including APIs that were never built in Mule. That federated capability, alongside developer portals, versioning and analytics, is a full API platform.

Boomi moved into this territory deliberately. Following its APIIDA acquisition in 2024 it added a vendor-agnostic federated API management control plane, and its gateway documentation lists more than 20 policies with a full lifecycle from deploy through versioning to retirement across environments.

Workato's API Platform turns recipes into endpoints with access profiles and throttling, governed by a workspace-level API concurrency limit that either queues or rejects requests once exceeded, with a configurable queue size between 1 and 100. Raising that ceiling requires a conversation with your customer success manager.

Celigo's API Builder arrived in April 2025 and is the newest and shallowest of the four.

‍

Event-driven architecture and messaging capabilities

MuleSoft leads clearly here. Anypoint MQ provides standard queues with at-least-once delivery supporting up to 120,000 in-flight messages per queue, and FIFO queues with exactly-once semantics, 10 in-flight messages per message group and unlimited message groups.

Dead-letter queues are native, message exchanges handle publish and subscribe fan-out, and the JMS connector covers JMS 1.0.2, 1.1 and 2.0 alongside ActiveMQ and Kafka. Redelivery policies and transactional scopes give you the idempotency controls that financial reconciliation work demands.

Boomi provides its own queueing plus JMS connectivity, and Atom Queue for asynchronous buffering between processes. Workato offers Kafka connectivity, including schema registry support through the on-prem agent, and event-driven triggers, without a native broker offering exactly-once delivery. Celigo relies on per-connection FIFO queues, and its Concurrency ID lock template exists specifically to stop concurrent updates landing out of order.

‍

Documented platform limits and behaviour at ten times the volume

‍

Those SLA figures deserve care. Boomi's published SLA commits to 99.99% service availability monthly with a credit as the sole remedy, and schedules weekly maintenance on Saturdays between 3am and 7am Eastern, while test runtime clouds carry no SLA at all.

Salesforce's MuleSoft Cloud Offerings SLA states not less than 99.95% each calendar month, and credit eligibility requires the application to be deployed to two or more production workers. Celigo commits to 99.95% per calendar quarter minus permissible downtime.

Workato publishes no specific percentage in a legal document. Its marketing references 99.9% uptime and its documentation refers to contractual SLAs agreed per customer, so if availability is a board-level concern, get that number written into your agreement.

The asymmetry in that table matters more than any individual figure in it. A tenfold volume increase on Boomi or MuleSoft is an infrastructure purchase you control, while on Workato or Celigo the same growth becomes a commercial negotiation.

‍

Licensing mechanics and the architecture each model punishes

Every metering model taxes one specific shape of architecture, and you can predict which one from the unit.

Boomi meters unique connections, defining each entitlement as one unique connection per runtime identified by component ID, so multiple connectors and operations sharing a single connection component count once. Connector classes vary by tier, covering Small Business, Standard, Enterprise and Trading Partner. This model punishes architectures with many distinct endpoints and rewards consolidation.

MuleSoft charges by vCore, with gateway licensing handled separately, which means many small applications waste vCore minimums. Fractional sizing on CloudHub 2.0 and 0.02 vCore deployments on Runtime Fabric partially fix that.

With Workato the unit is the task, so row-by-row processing of large record sets is where costs climb fastest. Its high-volume recipe tiering acknowledges as much, with Tier 3 covering recipes consuming more than 30 million tasks.

Celigo prices on flows and endpoints, with Integration Apps licensed on top, and fan-out architectures accumulate flows quickly.

‍

EDI and B2B trading partner support

This is a genuine capability gap that most comparisons flatten into a single yes.

Boomi supports the broadest set. Its documentation lists ASC X12, HL7, RosettaNet, UN/EDIFACT, TRADACOMS and ODETTE, with communication methods including AS2 providing digitally signed receipts through MDNs, plus DISK, FTP, HTTP, MLLP, OFTP2 and SFTP. It is the only platform here treating healthcare HL7 as a first-class standard, and EDI capability sits in a separately licensed edition.

MuleSoft covers X12, EDIFACT, Tradacoms and RosettaNet through Anypoint Partner Manager over AS2, SFTP, FTP, FTPS and HTTPS, with connector entitlements required. It works, and it takes more build effort than a purpose-built EDI tool.

Celigo's B2B Manager translates X12 and EDIFACT into JSON with 997 and CONTRL acknowledgements, and supports AS2, a VAN connector and file transfer protocols. There is no HL7 or RosettaNet support, which keeps Celigo inside retail and ERP-centric supply chains.

Workato is the clear weak spot of the four. Its native EDI actions generate and parse documents, and its own documentation states that use cases requiring more than that are served through its partnership with Orderful. For a serious trading partner network, that means a second vendor and a second contract.

‍

Lock-in and realistic exit cost

None of these four produces artefacts that run on a competitor's engine, so exit means rebuild and the honest question is how large that rebuild is.

Boomi processes export as proprietary XML that documents your logic without porting it. Workato recipes export as JSON, portable within Workato. Celigo flows clone within Celigo, and Integration Apps are vendor-managed content that loses all value away from NetSuite.

MuleSoft artefacts move freely between CloudHub, Runtime Fabric and on-premise deployments, which is real portability inside the platform.

The version boundary is the harder problem, because Mule 3 to Mule 4 was a rewrite rather than an upgrade once the engine, the transformation language and the connector model all changed, and Mule 3 has now reached end of life.

Current long-term support releases give roughly 18 months of standard support plus six months extended, with 4.11.x current as of April 2026. TLS 1.0 and 1.1 inbound traffic is blocked from 31 October 2026, which forces movement for anyone still on legacy runtimes.

‍

Where each platform is the right choice and where it is the wrong one

‍

That final row applies to all four, and it is the recommendation I give most often. An iPaaS moving millions of rows into a warehouse row by row is an expensive way to do work that ELT tooling does natively. Boomi's acquisition of Rivery in 2024 addresses change data capture and ELT as a separate product line rather than through the integration platform itself.

Beyond that, each platform has a scenario where I would remove it from the shortlist. MuleSoft comes off the list when the team has no dedicated engineers, because DataWeave maintenance becomes an unfunded liability the moment the integrator's contract ends.

Workato and Celigo are both eliminated as soon as a regulator requires payload data to stay inside customer infrastructure. Celigo carries a second disqualifier, since the prebuilt content that justifies the platform stops applying when the core systems are SAP, Oracle or Dynamics rather than NetSuite. And Boomi drops out when the primary deliverable is a portfolio of reusable API products, where MuleSoft's gateway and lifecycle tooling sits a level ahead.

‍

How to run the evaluation

Sequence matters more than scoring here, so run these five steps in order.

‍

• Answer the residency question in writing, with your compliance owner. Document whether payload data may reside in a vendor cloud. Two platforms disappear if the answer is no, and you have saved weeks of evaluation effort.
• Name the dominant workload. EDI volume, ecommerce order flow, API productisation and citizen-led automation each point to a different platform, so weight the shortlist toward whichever workload carries the most risk.
• Model licensing against the metric you cannot control. Count unique connections for Boomi, projected tasks for Workato, application count against vCore minimums for MuleSoft, and flows and endpoints for Celigo. If projected cost grows faster than linearly against a metric the business controls rather than IT, choose a platform metered on a different axis.
• Proof of concept on your hardest transformation and your peak volume. Demo datasets prove nothing, so run the reconciliation job that breaks things, at the volume you expect in 18 months.
• Test the failure paths rather than the happy path. Force a Boomi cluster node failure and watch connector thread behaviour, push Workato and Celigo to their documented concurrency ceilings, and hand a DataWeave transformation to the engineer who will maintain it after the integrator leaves.

Choose on runtime and residency first, workload second, features last. The feature matrix is the easiest artefact to build and the least predictive of whether the platform still fits in three years.