An integration platform as a service (iPaaS) connects an organization's applications, APIs, databases and files through one central layer instead of direct links between each pair of systems. With most iPaaS products, that layer is software owned and operated by a vendor, and integrations are built in the vendor's own designer and formats.
An open-source iPaaS is the same layer with its complete source code public. It runs wherever the organization deploys it - on-premises, in a private cloud or with any public cloud provider - and the integrations built on it belong to the organization.
Zato is an open-source iPaaS in Python, and it is the example used throughout this article. The guide to what iPaaS is and how it works in Python covers the iPaaS concept itself.
What open source means for an iPaaS
Many integration products publish part of their code. Some publish a core and keep functions such as high availability, monitoring or the most widely used connectors in a commercial edition. Others publish code that can be read but not used freely in production. Two questions establish what an organization actually receives:
- Is the whole platform open source, or only a core with a commercial edition built around it?
- Is the software the organization runs itself the complete product, or a reduced version of a hosted service?
In Zato, the whole platform is open source - every connector, the Dashboard, the scheduler, security, monitoring and the API portal. There is no community edition, no enterprise edition and nothing metered. The services and integrations an organization builds on the platform are its own and can remain private. The license page covers the common questions in detail.
What open source changes about the iPaaS model
The organization chooses where it runs. Zato runs on-premises, in AWS, Azure, GCP or a private cloud, from the same image in each case. Organizations in defense, health care and finance are often not permitted to send their data through a third-party cloud, and with a self-hosted platform the data stays within their own perimeter, under their own security policies.
The source code can be read. The entire platform is on GitHub. When a connector behaves unexpectedly in production, engineers read its implementation instead of waiting for a vendor's answer to a support ticket, and security teams audit the code instead of relying on vendor assurances. Every Zato Docker image also includes a Software Bill of Materials listing the exact version of every package the installation runs, with a signed attestation in the image registry.
Nothing is metered. There are no per-core licenses, no per-task charges, no per-connector tiers and no capacity-based subscriptions to renegotiate when traffic grows. An integration that processes ten times more messages this year than last year needs more infrastructure and no change to any contract.
Integration logic is portable. Integrations in Zato are Python code, stored and versioned in the organization's own Git repository. Python is a general-purpose language, not a transformation dialect that only one vendor's runtime executes, so the logic and the skills of the team that wrote it remain usable whatever platform decisions follow.
The platform does not depend on a vendor contract. The platform keeps running, and can be patched and supported, without any agreement with the company that builds it. The next section explains why this matters.
Business continuity when a vendor retires its product
A proprietary integration platform exists for as long as its vendor decides to sell and maintain it. The vendor sets the end-of-support date, chooses the successor and sets the terms on which customers move to it. Recent years show what this means in practice:
- Microsoft retired the Azure Logic Apps Integration Service Environment on 31 August 2024. Workflows stopped running in September and October 2024, customers could export them until 28 February 2025, and the instances that remained were then deleted together with their data (Microsoft).
- Microsoft BizTalk Server 2020 is the final version of the product. Sales end in March 2027, mainstream support in April 2028 and extended support in April 2030 (Microsoft).
- SAP Process Orchestration 7.5 leaves mainstream maintenance at the end of 2027, with extended maintenance until the end of 2030 (SAP). The migration tooling does not convert custom adapter modules, JDBC and RFC lookups or Java mappings, which are rewritten by hand.
- General support for Informatica PowerCenter 10.5.x ended on 31 March 2026, with paid extended support until March 2027 (Informatica).
In each case, the successor is the vendor's own cloud service under a different licensing model. The integration logic, written in the retired product's designers and mapping formats, is converted with partial tooling or rewritten, on a timetable the customer did not choose and under terms the customer negotiates without an alternative. Acquisitions create the same risk in another form - when an integration platform changes owner, its roadmap, pricing and support terms change owner with it, as when IBM acquired webMethods in 2024 and Salesforce acquired Informatica in 2025.
An open-source platform removes this dependency. The code of every published release remains available, and the organization, or any support provider it chooses, can continue to run, patch and extend it. No external party can stop a self-hosted installation or delete its data. The integrations are Python code in the organization's own repository, so they remain readable and maintainable regardless of what happens to any vendor. Commercial support is a decision the organization can renew, change or end without any effect on the running platform.
Open-source projects also come to an end. The difference is that the code, and the ability to maintain it, stay with the people who use it.
The people who build the integrations
Integration work in Zato is back-end Python work. A service calls REST APIs, runs SQL queries, reads from queues and file transfers and transforms data, in the same language and with the same libraries, tests and tools as any other Python back-end application.
The people who build and maintain the integrations therefore come from the general pool of Python back-end developers, not from the smaller pool of specialists trained and certified in one vendor's designer and mapping language. That pool is large - Python ranks first in the TIOBE index of October 2026, and 58 percent of the respondents to the 2026 Stack Overflow Developer Survey report extensive work in it, ahead of Java in every year since 2019.
For the organization, this has three consequences:
- Integration developers are hired from the same pool as the data, AI and automation teams, and can move between those teams.
- A new developer learns the platform's API, not a new language.
- The skills remain usable if the platform ever changes, which is the continuity argument applied to people.
The Python iPaaS article covers the hiring argument in full.
Who provides the service
An iPaaS is, by name, a platform delivered as a service. With a self-hosted open-source iPaaS, the organization's own platform or integration team provides that service. The team runs Zato and offers it to application teams, who use the Dashboard, the connection and security definitions and the monitoring as the interface of the service, in the same way they would use a vendor-hosted platform.
What operating the platform involves
A self-hosted platform is operated by the organization that runs it. In Zato, the operational model consists of the following:
- Deployment. Each environment runs from one Docker image, the same from development through testing to production, on any host that runs Docker or under Kubernetes with Helm.
- Configuration. Channels, connections, security definitions and scheduled jobs are exported to YAML with enmasse, kept in Git and imported by each container when it starts, so every environment is rebuilt from version control.
- Updates. Updates are installed from the Dashboard, on demand or on a schedule, or by replacing the container with a newer image referenced by its digest, as described in updating environments.
- Monitoring. Each environment exposes a Prometheus metrics endpoint for channels, outgoing connections, services and scheduler jobs, and writes its logs to the container output for collection by the organization's log platform.
- High availability. An active container processes the traffic and a standby container takes over when the active one stops responding to its ping endpoint, as described in the architecture overview.
- Production readiness. The settings to apply before an environment receives production traffic are listed in production best practices.
Enterprise support is available 24x7x365 from the team that builds Zato, from initial setup and architecture guidance to production troubleshooting. The support relationship is optional, and its business model depends on the organization's success with the platform rather than on its dependency on it.
What an integration looks like
Zato provides a Dashboard with connectors for REST, SQL, SFTP, LDAP, HL7, IBM MQ, Salesforce, Microsoft 365 and many more, together with scheduling, security definitions and monitoring. The part that ties systems together is a service - a Python class that receives a request, calls other systems and returns a response.
The service below receives a new order and forwards it to the REST API of a fulfillment system:
# -*- coding: utf-8 -*-
# Zato
from zato.server.service import Service
class OrderSync(Service):
""" Receives a new order and forwards it to the fulfillment system.
"""
name = 'api.order.sync'
def handle(self):
# Read the order from the incoming request
order = self.request.payload
# Get a connection to the fulfillment system's REST API
conn = self.rest['Fulfillment API']
# Send the order and read the response
response = conn.post(self.cid, order)
# Return the fulfillment ID to the caller
self.response.payload = {'fulfillment_id': response.data['id']}
The connection definition, its security and the REST channel that exposes the service are configured in the Dashboard. The business logic is a few lines of Python that any developer can read, test and keep in version control like any other code.
To build an integration step by step, follow the API integrations tutorial.
Open-source and vendor-hosted iPaaS compared
| Property | Vendor-hosted iPaaS | Open-source iPaaS |
|---|---|---|
| Where the runtime executes | The vendor's cloud, or vendor agents in the customer's network | Any infrastructure the organization chooses |
| Where data is processed | In the vendor's cloud, for flows executed there | Within the organization's own perimeter |
| What determines the cost | Subscription tiers, connectors, tasks or capacity | Infrastructure, and commercial support if chosen |
| Access to source code | None | The complete platform |
| Operation without a vendor contract | Not possible | Possible |
| Lifetime of the product | Set by the vendor | Set by the organization |
| Format of integration logic | The vendor's designer, mapping language or scripting dialect | Python code in Git |
| Who operates the platform | The vendor | The organization, with optional commercial support |
Industry use cases
An open-source iPaaS is used where control over data and infrastructure is a requirement. Networks in the defense industry connect contractors, military units and agencies that cannot route their data through a commercial cloud. Airports exchange flight, baggage, security and ground-service data between systems from dozens of suppliers in real time. Telecom operators connect OSS, BSS and provisioning systems at message volumes where per-task pricing is impractical. Health care providers connect electronic health records, HL7 and FHIR interfaces and billing systems while keeping patient data inside their own infrastructure.
Frequently asked questions
What is an open-source integration platform (iPaaS)?
An iPaaS connects different systems, applications and data sources so they can work together. An open-source iPaaS also makes the platform's complete source code public and runs on infrastructure the organization chooses - its own servers or any cloud.
Is Zato an iPaaS?
Yes. Zato is an open-source iPaaS in Python that connects applications and services and automates workflows, combining a Dashboard with a Python programming environment. For a comparison with the enterprise service bus model, see the article on the open-source ESB in Python.
Is Zato open-source software that I can find on GitHub?
Yes. The platform's complete source code is on GitHub.
Is Zato open core?
No. The whole platform is open source, and no function is reserved for a commercial edition.
Is an open-source iPaaS free of charge?
Zato has no license fees and no subscriptions, and nothing is metered. The costs of running it are the infrastructure it runs on and, if the organization chooses, commercial support.
Do my own integrations have to be published?
No. The services and integrations built on Zato belong to the organization that builds them, and they can remain private and proprietary.
What is the difference between open source and source-available?
Source-available software publishes its code but restricts how it may be used, for instance in production or as a hosted service. Open-source software can be used, modified and run for any purpose.
Is an open-source iPaaS suitable for critical production workloads?
Yes. Production suitability depends on how a platform is operated, not on whether its code is public. Zato has documented practices for deployment, configuration in Git, updates, monitoring and high availability, and enterprise support is available for production environments.
What happens to my integrations if my iPaaS vendor retires its product?
On a proprietary platform, the integrations are converted with partial tooling or rewritten for the vendor's successor product. On Zato, the integrations are Python code in the organization's own repository and the platform's code remains available, so no external decision forces a rewrite.
Can Python back-end developers build the integrations?
Yes. Integrations in Zato are Python services that call APIs, databases, queues and files, so any Python back-end developer can build and maintain them after learning the platform's API.
Can Zato run alongside an existing iPaaS?
Yes. Zato connects to the same APIs, queues and databases as the existing platform, so integrations move one at a time. The article on the open-source ESB describes the migration sequence.
How do I get started with iPaaS in Python?
Start the API integrations tutorial or schedule a meaningful demo with an expert who will help you become fluent in API integrations.
- John Adams