[Articles](https://zato.io/articles/index.html)
# Open-Source MuleSoft Alternative (in Python)
**MuleSoft Anypoint Platform is an integration and API management platform owned by Salesforce.
This article describes how its cost model and release cadence affect the organizations that run it, maps Mule concepts to an open-source platform in Python and presents a sequence for moving Mule applications to it.**
By Dariusz Suchojad
12 min. read
Share this article: [LinkedIn](https://www.linkedin.com/sharing/share-offsite/?url=https%3A%2F%2Fzato.io%2Farticles%2Fopen-source-mulesoft-alternative.html) | [FB](https://www.facebook.com/sharer/sharer.php?u=https%3A%2F%2Fzato.io%2Farticles%2Fopen-source-mulesoft-alternative.html) | [Email](mailto:?subject=Open-Source MuleSoft Alternative article from zato.io&body=https://zato.io/articles/open-source-mulesoft-alternative.html)
- - -
A Mule application is a set of flows defined in XML. Each flow begins with an event source, such as an HTTP listener or a scheduler, and continues through connector operations, routers and DataWeave transformations. The applications run on the Mule runtime, which is deployed to CloudHub, to Runtime Fabric or to the organization's own servers, and Anypoint Platform adds the design, management and governance tools around them - API Manager, Exchange, Runtime Manager and the IDEs.
Salesforce [completed its acquisition of MuleSoft](https://www.salesforce.com/news/press-releases/2018/05/02/salesforce-completes-acquisition-of-mulesoft/) on May 2, 2018, at an enterprise value of approximately 6.5 billion USD. Since then the product direction of Anypoint Platform has been set within Salesforce.
Organizations that evaluate an alternative to MuleSoft usually start from one of three circumstances. The renewal quote has grown with the number of integrations, a runtime or hosting upgrade has become mandatory, or the integrations need to be maintained by engineers who are not Mule specialists. Each of these is examined below, followed by the way Mule applications translate into Python.
## How MuleSoft charges for integrations {#how-mulesoft-charges-for-integrations}
At the end of 2023 MuleSoft [introduced usage-based pricing](https://blogs.mulesoft.com/news/usage-based-pricing-for-hybrid-standalone/), which replaces the earlier allocation of vCores with entitlements for three quantities. The [usage metrics documentation](https://docs.mulesoft.com/general/usage-metrics) defines them as follows.
1. **Mule flows.** Every flow that contains an event source or an APIkit route counts. The monthly figure is the highest number of such flows that exist in any single hour of the month.
2. **Mule messages.** A message counts when an event source triggers it, and all messages of the month are summed.
3. **Data throughput.** All bytes transferred in and out of the infrastructure that runs Mule count, including the traffic for monitoring, logs and health checks.
API Manager, Omni Gateway, Anypoint MQ and Object Store are metered separately, by managed API instances, gateway requests and API requests respectively. MuleSoft does not publish list prices, so the price of each entitlement is the outcome of a negotiation.
In this model architectural decisions become line items. Splitting one flow into two raises the flow count, a new partner that sends many small messages raises the message count, and a more detailed monitoring setup raises the throughput. An integration team then evaluates a design change against its effect on the contract as well as on its technical merit.
Zato has no per-flow, per-message or throughput charges. You run it on your own infrastructure, with [enterprise support](https://zato.io/services/index.html) available 24x7x365 from the team that builds Zato.
## The release cadence of the Mule runtime {#the-release-cadence-of-the-mule-runtime}
Since Mule 4.5 the runtime is released in [two channels](https://docs.mulesoft.com/release-notes/mule-runtime/lts-edge-release-cadence). Edge versions are released up to three times a year and receive standard support until one month after the next Edge release, followed by three months of extended support. Long-Term Support versions are released each February and receive at least 18 months of standard support and 6 months of extended support. Mule 4.9 and later versions require Java 17.
An organization on the LTS channel therefore plans a runtime upgrade roughly every two years at the latest, and an organization on the Edge channel several times a year. Earlier transitions were larger. The extended support of Mule 3.9 ended on March 20, 2024, and the move to Mule 4 replaced the Mule Expression Language with DataWeave 2. MuleSoft states that its Mule Migration Assistant [does not deliver a fully functional app](https://docs.mulesoft.com/mule-runtime/4.4/migration-intro), and complex expressions and transformations are migrated by hand.
The hosting layer follows the same pattern. CloudHub 2.0 was released in August 2022, and MuleSoft [states](https://blogs.mulesoft.com/news/upgrade-to-cloudhub-2-0-with-our-in-app-upgrade-tool/) that CloudHub 1.0 will not be available indefinitely. During the migration both environments run at the same time with [double entitlements](https://docs.mulesoft.com/cloudhub-2/ch2-migration-plan), and the CloudHub 1.0 infrastructure is decommissioned within six months. The development tools change as well, as Anypoint Code Builder, based on VS Code, is [positioned to become the primary IDE](https://www.mulesoft.com/platform/api/anypoint-code-builder) in place of the Eclipse-based Anypoint Studio.
You upgrade a self-hosted Zato installation on your own schedule, and your integrations are Python code that you develop in any Python IDE.
## The community edition of Mule {#the-community-edition-of-mule}
MuleSoft distributes Mule Kernel, formerly Mule Community Edition. According to the MuleSoft documentation, Mule Kernel [does not provide all the functionality](https://docs.mulesoft.com/mule-runtime/latest/mule-4-api-javadoc) of the Mule runtime engine, and development with it is not supported in Anypoint Studio. The [mulesoft/mule repository](https://github.com/mulesoft/mule) on GitHub is archived. Mule Kernel is therefore not a replacement for Anypoint Platform for organizations that run production integrations on the commercial runtime.
## From drag-and-drop to Python {#from-drag-and-drop-to-python}
[](https://zato.io/docs/arch/index.html)
Anypoint Platform belongs to the generation of integration products built on Java. The Mule runtime is a Java application, Mule 4.9 and later versions require Java 17, and flows are assembled by dragging components onto the canvas of Anypoint Studio, with DataWeave scripts and expressions configured inside each component.
A drag-and-drop canvas makes the first flows easy to draw and every later flow harder to maintain. The logic is spread across the property panels of individual components, a change is reviewed as a diff of generated XML, and a fix to a pattern that recurs in fifty flows means opening fifty diagrams. Developers who build integrations every day work faster in code, which they read, search, review, refactor and test with the same tools as the rest of their work.
Python is the language of the next generation of integrations. It is the most widely used programming language, first in the [TIOBE index](https://www.tiobe.com/tiobe-index/) for October 2026, and the language of data engineering, machine learning and AI agents. Integrations written in Python are maintained by the developers you already employ, they use the same libraries as your data and AI work, and AI assistants write them fluently, which is also what makes the conversion of Mule flows with AI practical.
## Mule concepts and their Zato counterparts {#mule-concepts-and-their-zato-counterparts}
In Zato, the unit of integration logic is a service - a Python class that receives a request and produces a response. Services are exposed through channels, such as REST endpoints, and they reach external systems through outgoing connections defined in the Dashboard or in configuration files. The table maps the main building blocks of a Mule application to their counterparts.
| Mule and Anypoint | Zato |
| --- | --- |
| Flow and sub-flow | [Service](https://zato.io/docs/dev/invoking-services.html) |
| HTTP Listener | [REST channel](https://zato.io/docs/dev/rest/channels.html) |
| Connector configuration | [Outgoing connection](https://zato.io/docs/dev/rest/outconns.html), used by name in the service |
| DataWeave transformation | Python, with [data models and mappers](https://zato.io/docs/dev/rest/data-mapping.html) |
| Choice router | Python |
| Until Successful and redelivery policies | [Delivery retries and dead-letter queues](https://zato.io/docs/dev/delivery.html) |
| Anypoint MQ and VM queues | [Built-in topics and queues](https://zato.io/docs/dev/message-queues/index.html), AMQP, Kafka, IBM MQ and Azure Service Bus |
| Scheduler | [Scheduler](https://zato.io/docs/dev/examples/scheduler.html) |
| Object Store | [Built-in cache](https://zato.io/docs/dev/examples/cache.html) |
| API Manager policies | [Security definitions, security groups and quota tiers](https://zato.io/docs/api-management/index.html) |
| API portal in Exchange | [API portal](https://zato.io/docs/dev/rest/api-portal.html) |
| MUnit | [Built-in testing framework](https://zato.io/docs/api-testing/index.html) |
| Properties files per environment | [YAML configuration](https://zato.io/docs/admin/enmasse.html) in Git |
| Runtime Manager | Dashboard and command-line tools |
| Anypoint Monitoring | [Audit log](https://zato.io/docs/admin/audit-log/index.html) and [Prometheus metrics](https://zato.io/docs/monitoring/index.html) |
## A Mule flow rewritten in Python {#a-mule-flow-rewritten-in-python}
The flow below receives an order from a web shop over HTTP and builds a sales order with DataWeave. Orders above 10,000 are published to an Anypoint MQ destination for approval, and the remaining ones are posted to the ERP.
```xml
{
sku: item.sku,
quantity: item.quantity,
amount: item.price * item.quantity
}
---
{
orderNumber: payload.id,
customer: payload.email,
lines: lines,
total: sum(lines.amount)
}]]>
```
The flow combines two languages - Mule XML for the structure, and DataWeave for both the transformation and the routing condition. Under usage-based pricing the flow counts toward the Mule flows entitlement, and every order that reaches the listener counts as a Mule message.
The same logic as a Zato service:
```python
# -*- coding: utf-8 -*-
# stdlib
from dataclasses import dataclass
# Zato
from zato.common.typing_ import list_
from zato.server.service import Model, Service
@dataclass(init=False)
class Item(Model):
sku: str
quantity: int
price: float
@dataclass(init=False)
class Order(Model):
id: str
email: str
items: list_[Item]
class CreateSalesOrder(Service):
""" Creates a sales order in the ERP for each order from the web shop.
"""
name = 'orders.create-sales-order'
input = Order
def handle(self) -> 'None':
order = self.request.input
# Each line in the format of the ERP ..
lines = []
for item in order.items:
lines.append({
'sku': item.sku,
'quantity': item.quantity,
'amount': item.price * item.quantity,
})
total = sum(item.price * item.quantity for item in order.items)
sales_order = {
'orderNumber': order.id,
'customer': order.email,
'lines': lines,
'total': total,
}
# .. large orders wait for approval ..
if total > 10_000:
self.publish('orders.approval', sales_order)
# .. and all the other ones go straight to the ERP.
else:
self.response.payload = self.rest['ERP'].post(sales_order).data
```
The structure, the transformation and the routing condition are one Python class. The order model validates every incoming request and documents the API in its OpenAPI specification. The address of the ERP, its credentials and its timeouts belong to the ERP connection, so the same service runs in test and in production, and [hot deployment](https://zato.io/docs/dev/hot-deploy.html) puts each change live without a restart.
Because the service is a Python class, it is reviewed in pull requests and tested against recorded payloads with the [built-in testing framework](https://zato.io/docs/api-testing/index.html), which simulates the ERP connection without a running server.
## API-led connectivity in a single platform {#api-led-connectivity-in-a-single-platform}
MuleSoft recommends API-led connectivity, in which system APIs expose the records of individual back-end systems, process APIs combine them into business operations and experience APIs shape the result for a given consumer. In a typical Anypoint implementation each layer is a separate Mule application with its own deployment, and every call between the layers is an HTTP request.
In Zato the same layering consists of services that invoke each other. A system service reads customers from the CRM, a process service combines them with the orders from the ERP, and an experience service returns the fields that a mobile application needs. The layers call each other inside the same server, without a network hop, and only the services that your consumers call are exposed as REST APIs. You keep the separation of responsibilities without multiplying deployments and network calls.
## API management {#api-management}
Anypoint API Manager applies policies such as client ID enforcement and rate limiting to the APIs it manages. Zato provides the corresponding functions in the [API management](https://zato.io/docs/api-management/index.html) layer of the platform.
1. **Security.** REST channels are secured with [API keys](https://zato.io/docs/security/api-keys.html), basic authentication, bearer tokens or mutual TLS, and [security groups](https://zato.io/docs/security/groups.html) assign one set of credentials to many channels.
2. **Rate limits.** [Quota tiers](https://zato.io/docs/security/quota-tiers.html) are named rate-limit plans assigned to API clients, channels or security groups, with X-RateLimit headers in the responses.
3. **Documentation.** [OpenAPI specifications](https://zato.io/docs/dev/rest/openapi.html) are generated from the data models of the services, and the [API portal](https://zato.io/docs/dev/rest/api-portal.html) presents them to API consumers with a try-it client.
4. **External gateways.** Organizations that already operate Azure API Management, AWS API Gateway or Kong place it in front of Zato through a [gateway channel](https://zato.io/docs/dev/rest/api-gateways.html).
[](https://zato.io/docs/dev/rest/channels.html)
## Connectors and the systems behind them {#connectors-and-the-systems-behind-them}
Zato provides connections for REST, SOAP with WS-Security, OData, GraphQL, gRPC, SQL and NoSQL databases, AMQP, Kafka, IBM MQ, FTP, SFTP, SMB and LDAP, and for systems such as [SAP](https://zato.io/docs/dev/sap/index.html), [Salesforce](https://zato.io/docs/dev/salesforce/index.html), Microsoft 365, Jira, Confluence, AWS and Shopify.
Beyond them, every service has the entire Python ecosystem at its disposal. Vendors publish official Python SDKs for their products, and each of them is [installed into the platform](https://zato.io/docs/dev/python-packages.html) like any other Python library, so your services reach any system that offers an API.
## Moving Mule applications to Zato {#moving-mule-applications-to-zato}
A migration proceeds one flow at a time, and the Mule applications that have not been moved yet continue to run.
1. **Inventory the flows.** The usage reports in Access Management and the applications in Runtime Manager list every flow, together with the systems it connects to and the traffic it carries.
2. **Choose the first flows.** Flows with few dependencies and a well-defined contract, such as a scheduled synchronization or a single REST API, are moved first.
3. **Define the connections.** Every connector configuration that the chosen flows use becomes an outgoing connection in Zato, defined for each environment in YAML.
4. **Convert the flows with AI.** An AI assistant translates each Mule flow and its DataWeave scripts into a Zato service. With the Zato documentation [connected to the assistant over MCP](https://zato.io/docs/ai/connect-your-copilot.html), it writes the services against the real APIs of the platform. Your engineers review each service, and tests against payloads recorded from the production flow confirm that the service returns the same output as the flow.
5. **Run in parallel.** The Zato service receives a copy of the traffic, or a subset of the consumers, while the Mule flow remains the system of record.
6. **Switch the traffic.** The route in the load balancer or API gateway is changed for that one path, so that consumers keep the same URL.
7. **Decommission the flow.** The Mule application is stopped once the Zato service has handled production traffic for an agreed period, and its flows no longer count toward the Mule flows entitlement.
## The engineers who maintain the integrations {#the-engineers-who-maintain-the-integrations}
Mule development requires knowledge of the Mule XML configuration, of DataWeave and of Anypoint Platform, and MuleSoft runs its own certification program for these skills. An organization that runs MuleSoft either employs Mule specialists or contracts them from a MuleSoft partner.
Zato services are written in Python, which is used across back-end development, data engineering, automation and test engineering. The engineers who already maintain the back-end systems of the organization read and change the integrations in the same language and in the same Git workflow as the rest of their code.
## Where the platform runs {#where-the-platform-runs}
Anypoint Platform is managed through a control plane hosted by MuleSoft, and Mule runtimes run in CloudHub, in Runtime Fabric or on the organization's own servers. Organizations that require the control plane on their own infrastructure use [Anypoint Platform Private Cloud Edition](https://docs.mulesoft.com/private-cloud/latest/), which contains a subset of the platform services and excludes, among others, Anypoint MQ, Object Store and Anypoint Monitoring.
Zato runs entirely on the infrastructure that you choose - your own servers, Docker or [Kubernetes](https://zato.io/docs/admin/guide/kubernetes.html), on premises or in any cloud. The Dashboard, the servers and the configuration are part of the same installation, and no message passes through a vendor's environment unless you configure a connection to one.
[](https://zato.io/docs/admin/audit-log/index.html)
## MuleSoft and Zato compared {#mulesoft-and-zato-compared}
| | MuleSoft | Zato |
| --- | --- | --- |
| Open source | No | Yes |
| Integrations in the most popular programming language | No | Yes |
| Integrations as code instead of drag-and-drop diagrams | No | Yes |
| One language for flow logic and data mapping | No | Yes |
| No charges per flow, message or data volume | No | Yes |
| Runtime upgrades scheduled by yourself | No | Yes |
| The complete platform on your own infrastructure | No | Yes |
| Development in the IDE of your choice | No | Yes |
| The libraries of the most popular programming language in every integration | No | Yes |
| API management and an API portal | Yes | Yes |
## Frequently asked questions {#frequently-asked-questions}
### Can AI convert Mule flows and DataWeave to Python? {#can-ai-convert-mule-flows-and-dataweave-to-python}
Yes. An AI assistant translates Mule flows and DataWeave scripts into Zato services, and with the Zato documentation connected to it over MCP, it uses the real APIs of the platform. Your engineers review each service and test it against payloads recorded from the production flow before it takes over the traffic.
### Can Zato and MuleSoft run at the same time? {#can-zato-and-mulesoft-run-at-the-same-time}
Yes. During a migration both platforms run side by side, and Zato services call the remaining Mule APIs over HTTP like any other REST API.
### How does Zato handle API-led connectivity? {#how-does-zato-handle-api-led-connectivity}
The system, process and experience layers are services that invoke each other inside the same server, and only the services that external consumers call are exposed as REST channels.
### Does Zato connect to Salesforce? {#does-zato-connect-to-salesforce}
Yes. Zato has a [Salesforce connection](https://zato.io/docs/dev/salesforce/index.html) for creating, querying, updating and upserting records from Python services.
### Is Zato an iPaaS? {#is-zato-an-ipaas}
Zato is an integration platform that you deploy on your own infrastructure. The article on the [open-source iPaaS](https://zato.io/articles/open-source-ipaas.html) describes this model in detail.
### How do I get started? {#how-do-i-get-started}
Start the [tutorial](https://zato.io/tutorials/main/01.html) or [schedule a demo](https://zato.io/services/demo.html).
Dariusz Suchojad is founder of Zato Source.
**Planning a move from MuleSoft? [Request your customized demo today](https://zato.io/services/demo.html).**