Architecture

Zato is an open-source, Python-based, platform designed for integrations, automation, orchestration, interoperability, and the building of AI and API-first, server-side systems.

Terms like an AI control plane, MCP gateway, integration platform, IPaaS, enterprise service bus, API server, automation engine, service-oriented platform, interoperability engine or integration layer, are commonly used to describe the platform's capabilities.

Zato is specifically designed for people who want to use Python, often along with AI, to develop their integrations even faster.

Basic concepts

Each Zato environment runs in a Docker container. To streamline deployments, there is a single image that each environment uses, from development, through tests to production, it's always the same image.
An environment will run anywhere Docker will, on premises, in any cloud, with special support for Azure deployments available.
Hybrid deployments are supported - you can deploy in the cloud and use the built-in on-prem gateway to access your internal systems securely.
You can connect your LLM to help you design and build your environments and Python-based integrations.
Each environment has a server with its Dashboard and a scheduler for scheduled jobs and tasks that run in the background, as well as a rule engine for your Python services
A built-in message broker with message queues lets you implement publish/subscribe scenarios (Kafka and other brokers are supported too)
For B2B and other integrations, you can use SFTP, FTP or SMB for file transfer, including EDIFACT or HL7 messages
Your API partners can access a Swagger-like API portal
In addition to a plug-in for Visual Studio code, a built-in Python IDE is available directly through the Dashboard, without a need to install additional apps on your computer. Simply install Zato, and you have everything that's needed for work.
Deploy-on-save from your editor is provided out-of-the box - through the mounted project directory of the blueprint or through the VS Code plugin for a remote server.
Hot-deployment is one of the fundamental concepts in Zato, particularly during development - when you deploy a new version of a service to a server, only that one service will be reconfigured and changed, there is no need to restart an entire server in such a case. Hot-deployment of new functionality is counted in milliseconds.
For DevOps and CI/CD pipelines, to ensure repeatable builds, you can export the entire configuration of your services to a YAML file that can be stored and versioned in git, and a container will import its contents when it's starting.

Server and API integrations

Requests are accepted by so called channels and external resources are accessed through what is known as outgoing connections.
The server executes business services written in Python - to learn more about what a Zato service is, read the high-level overview.
Services can be independent of a particular data format of channel, e.g. the same service can use REST, JSON-RPC, File transfer, IBM MQ, AMQP, HL7 or other communication means.
Services require little RAM in runtime and little time to deploy. A typical service will consume roughly 1 MB of RAM when idle and will require less than 1 ms to deploy. Hence, even a server with 500 or 1000 services will require little computing resources to operate, implying low electricity and cooling costs as well as low CO₂ emission and environmental impact.
Services can accept requests through a range of channels. They can invoke other systems through one of many outgoing connection types, such as REST, GraphQL, AMQP, Microsoft 365 or other cloud services, HL7, SQL, MongoDB and various others typically used in backend environments.
The server acts as a cache with a Python API for your services. The contents of the cache is also accessible through the server's dashboard.

Scheduler

Each environment may use a highly configurable scheduler whose jobs can be triggered in predefined intervals.
Each job invokes a service on the server. Because services are protocol independent, it means that the same service can be made available to external API clients and, internally, to the scheduler as well.
It is possible for services to schedule jobs dynamically in runtime, for instance, in reaction to other events taking place in integration processes, e.g. a zero-trust network may offer access to resources through automation that creates accounts on demand and then cleans everything up after N minutes.

Publish/subscribe message broker

The server acts as a publish/subscribe message broker offering topics and queues to asynchronous publishers and subscribers.
The message broker is multi-protocol and can be used by Python, REST or File transfer clients. The Dashboard acts as a GUI to manage the topics, queues and endpoints participating in pub/sub integrations.

On-prem systems

When Zato runs in the cloud, the on-prem gateway connects it to the databases, APIs and other systems in your private network.
The gateway is installed on a host in the private network and connects out to the Zato container over HTTPS, so there is no VPN and no inbound firewall rule to open.
Outgoing connections use the addresses of the on-prem systems as they are, e.g. erp-db.corp.local:5432, and the same connection definitions work whether Zato runs in the cloud or in the same network as the systems.

High availability

High availability can be achieved with an active/standby setup, in which one container processes all the traffic, and one or more stand by, ready to take over when needed.
Your monitoring tool can check the active container's ping endpoint, and if the endpoint stops responding, it can trigger a script in your CI/CD pipeline. The script can then stop the active container, start a container on the standby host and update the load-balancer to send the traffic to that host.
Since a container imports its services and configuration from the project directory of its project git clone each time it starts, the new container will offer the same channels, services and scheduled jobs as the one it replaces.
Because each container runs a same scheduler with the same configuration, if you use scheduled jobs in your integrations, make sure to start such a standby container only after the active one has stopped.