Scaling and Load
Learn how to scale ZigiOps vertically or horizontally, choose the right deployment size, and configure high availability with automatic failover.
How to size, scale, and ensure high availability for ZigiOps.
ZigiOps is designed to be lightweight and efficient, but integration workloads vary widely in volume, frequency, and complexity. This page explains how to choose the right deployment size for your environment, how to scale vertically or horizontally when workloads grow, and how to configure high availability so that your integrations continue operating in the event of a server failure or planned maintenance.
Related pages: System Requirements, Installation (Linux), Installation (Windows), Troubleshooting, Logs.
How do I choose the right deployment size?
ZigiOps is offered in two deployment sizes: Small and Enterprise. The right choice depends on the volume of integration data flowing through your environment. Use the table below to identify which deployment fits your expected workload.
Small
10,000
100
100
100
Enterprise
10,000 – 100,000
200
300
200
These figures represent averages. Workload spikes, complex field mappings, or a high number of concurrent integrations can affect throughput. If you are consistently operating near the upper limit of your tier, consider scaling up or out before performance is affected.
What hardware does each deployment size require?
The table below shows the minimum infrastructure requirements for each deployment type. These are the resources required on the server where ZigiOps is installed.
Small
Dual-Core Processor (2.8 GHz or more)
4 GB or more
10 GB or more
Enterprise
Quad-Core Processor (2.8 GHz or more)
8 GB or more
20 GB or more
Disk space requirements may increase if HTTP data and payload data collection are enabled for troubleshooting purposes, or if the Debug log level is left active for extended periods. See the Logs page for guidance on managing log data and purging intervals.
What are the two types of scaling in ZigiOps?
ZigiOps supports two methods of scaling to handle larger integration workloads: vertical scaling and horizontal scaling. The right approach depends on how much your current workload exceeds your existing deployment capacity.
Vertical scaling
Vertical scaling means increasing the resources available to your existing ZigiOps instance: adding more CPU, memory, or storage to the same server. This is the recommended first step when your current deployment is under-resourced but still within a single-instance model.
Vertical scaling is appropriate when your workload exceeds the Small deployment tier but does not yet require distributing the load across multiple instances.
Horizontal scaling
Horizontal scaling means adding more ZigiOps instances and distributing the integration workload across them. Each instance runs a distinct set of integrations. This approach is recommended when actual data volumes consistently exceed the capacity of the Enterprise deployment tier.
ZigiOps supports horizontal scaling through a logical, manual distribution of workloads rather than automated routing or dynamic load balancing. Integration workflows must be explicitly assigned to specific instances to ensure optimal performance and data consistency. Each workflow, along with its connected source and target systems, should reside entirely on the same ZigiOps node. This allows instances to operate independently, eliminating the need for a shared state or complex cross-instance routing.
In a horizontal scaling setup, each ZigiOps instance operates independently with its own set of integrations. There is no automatic routing of requests between instances.
What is high availability in ZigiOps and how does it work?
ZigiOps high availability (HA) ensures that your integrations can continue operating in the event of a server failure or planned maintenance downtime. The HA model in ZigiOps consists of a Primary server and one or more Backup servers. Only one server is active at any time. When the Primary server becomes unavailable, a Backup server can take over through a failover procedure.
ZigiOps is designed with a minimal integration state footprint. The entire state needed to resume integration from where the Primary stopped is contained in a small set of runtime files (a few kilobytes in total). Synchronising these files to the Backup server is all that is required for the Backup to take over without gaps in data.
The Backup ZigiOps server must always remain stopped while the Primary server is active. Running two active instances simultaneously will cause data conflicts.
No shared file system, external database, or network storage mount is required for a standard HA setup. The HA model relies on copying a small set of runtime files from the Primary to the Backup before failover. For Linux deployments, an optional network storage mount can be used to make the runtime files accessible to both servers without a manual copy step. See Network Storage for Runtime Files for details.
What are the requirements for high availability?
Before configuring HA, ensure that your environment meets all of the following requirements:
Hardware parity
Primary and Backup servers must be comparable in hardware, memory, and performance
Software version parity
The same version of ZigiOps must be installed on both Primary and Backup servers
Configuration sync
Integration configuration must be kept in sync across both servers at all times
Active licenses
A valid license must be active on each ZigiOps instance (Primary and Backup)
Single active instance
Only one ZigiOps server may be active at any time; the passive server must remain stopped
Load Balancer VIP
Required only when integration actions use Listener-type triggers. One VIP per unique port number used by a Listener action.
How do I configure high availability?
The steps below assume that the Primary ZigiOps server is already configured with integrations and that valid licenses are applied on both instances.
Install ZigiOps on the Backup server
Install the same version of ZigiOps on the Backup server as is running on the Primary.
Stop ZigiOps on the Backup server immediately after installation. The Backup must remain stopped while the Primary is active.
Synchronise the integration configuration to the Backup server
Stop ZigiOps on the Primary server, then copy the following directories from the Primary to the Backup:
Windows
C:\ZigiWave\ZigiOps\webapp\conf
Windows
C:\ZigiWave\ZigiOps\platform\conf
Linux
/opt/zigiwave/zigiops/webapp/conf
Linux
/opt/zigiwave/zigiops/platform/conf
Docker
webapp volume: /conf
Docker
platform volume: /conf
Start ZigiOps on the Primary server.
Leave the Backup ZigiOps service stopped.
Repeat this synchronisation step every time you make a configuration change on the active server. The integration configuration on the Backup must always reflect the current state of the Primary.
How do I perform a failover to the Backup server?
Use the following procedure to move the active ZigiOps instance from the Primary to the Backup server. This procedure applies to standard (non-Listener) integrations. For integrations using Listener-type triggers, see Section 8.
Stop the Primary ZigiOps server
Copy the runtime files from the Primary to the Backup server
The runtime file paths are:
Windows
C:\ZigiWave\ZigiOps\platform\conf\settings\runtime
Linux
/opt/zigiwave/zigiops/platform/conf/settings/runtime
Docker
platform volume: /conf
Start ZigiOps on the Backup server
In a disaster scenario where the Primary server is completely unavailable and the runtime files cannot be copied, delete the runtime files on the Backup server and start ZigiOps clean. The integration will resume from the current state of the connected systems. This may result in a gap in data for the period between when the Primary stopped and when the Backup started.
How does high availability work for Listener-type triggers?
Integration actions configured with a Listener-type trigger make ZigiOps the passive side of the integration: it waits to receive HTTP requests from the connected system. When a failover occurs, the host serving the Listener endpoint changes, which means the connected system would need to redirect its requests to a different address.
To avoid manual reconfiguration of the connected system during every failover, ZigiOps supports placing a Load Balancer (LB) in front of the ZigiOps instances. The connected system sends all requests to the Load Balancer VIP rather than directly to a ZigiOps host. The Load Balancer uses HTTP health monitors to detect which ZigiOps instance is active and routes traffic accordingly. This enables automatic failover for Listener-based integrations.
ZigiOps operates in active/passive mode. The Load Balancer will always route to the single active instance based on health monitor responses.
Requirements for Listener HA
All standard HA requirements listed in Section 5 apply.
External Load Balancing software capable of HTTP health monitoring.
One VIP per unique port number used by a Listener action. For example: if three actions use HTTPS on port 9090 and one action uses HTTP on port 9494, two VIPs are required.
Configuring the Load Balancer VIP
Create a pool in the Load Balancer that contains all ZigiOps servers included in the HA setup.
Configure the forwarded requests to preserve the original Host header.
Forward Proxy is not supported.
There are no restrictions on the load balancing method and no requirements for session persistency.
Configuring HTTP health monitors
Configure one HTTP health monitor for each VIP using the following parameters:
Monitor type
HTTP
Port
The port used in the Listener action (for example: 9090)
Send string
GET method against the PATH used in the Listener action (for example: /listener/omi)
Receive string
HTTP 200 OK
Failover procedure for Listener integrations
Stop the Primary ZigiOps server
Start the Backup ZigiOps server
The Load Balancer will detect the state change via its health monitors and automatically redirect incoming requests to the now-active Backup instance. No changes are needed on the connected system side.
Only one ZigiOps instance may be active at any time, even in a Listener HA configuration with a Load Balancer in front of it. Starting both instances simultaneously will cause duplicate processing of events.
What are the best practices for scaling and high availability?
Plan ahead: Size your deployment before go-live.
Vertical before horizontal: Scale vertically first when a single-instance deployment approaches its limits. Adding resources to an existing server is simpler and carries less operational overhead than adding instances.
Always keep configuration in sync: Keep the integration configuration in sync between Primary and Backup servers after every change. Stale configuration on the Backup is one of the most common causes of post-failover issues.
Test failover before you need it: Test failover in a non-production environment before relying on it in production. Confirm that the Backup can resume all integrations correctly, and that runtime file synchronization is working as expected.
Use a Load Balancer for Listener integrations: For Listener-based integrations in a production HA environment, always use a Load Balancer VIP. Manual redirect of the connected system during a failover introduces downtime.
Keep versions in sync: Keep the same version of ZigiOps installed on all instances at all times. Version mismatches between the Primary and Backup can cause runtime file incompatibility.
Consider network storage for runtime files (Linux only): For Linux deployments, mounting a shared network path for runtime files removes the need to manually copy files during failover. See Network Storage for Runtime Files for configuration details.
Where can I go from here?
The following pages are closely related to the topics covered on this page:
System Requirements - Full hardware, software, OS, and network requirements for deploying ZigiOps
Installation (Linux) - Step-by-step installation guide for Linux deployments
Installation (Windows) - Step-by-step installation guide for Windows deployments
Logs - How to manage log data, debug log levels, and purging settings, which affect disk usage on scaled deployments
Troubleshooting - How to diagnose integration issues using action run phases and exported diagnostic data
Last updated
Was this helpful?