> For the complete documentation index, see [llms.txt](https://docs.zigiwave.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.zigiwave.com/operations-and-monitoring/scaling-and-load.md). # Scaling and Load 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](/integration-platform/system-requirements.md), [Installation (Linux)](/installation-and-deployment/installation-linux.md), [Installation (Windows)](/installation-and-deployment/installation-windows.md), [Troubleshooting](/operations-and-monitoring/troubleshooting.md), [Logs](/operations-and-monitoring/logs.md). ### 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. | Deployment | Configuration Items | Events / sec | Metrics / sec | ITSM / DevOps Records / sec | | ---------- | ------------------- | ------------ | ------------- | --------------------------- | | Small | 10,000 | 100 | 100 | 100 | | Enterprise | 10,000 – 100,000 | 200 | 300 | 200 | {% hint style="info" %} 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. {% endhint %} ### 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. | Deployment | CPU | RAM | Disk | | ---------- | ------------------------------------- | ------------ | ------------- | | 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 | {% hint style="info" %} 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. {% endhint %} ### 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. {% hint style="info" %} 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. {% endhint %} ### 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. {% hint style="info" %} The Backup ZigiOps server must always remain stopped while the Primary server is active. Running two active instances simultaneously will cause data conflicts. {% endhint %} 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: | Requirement | Details | | ----------------------- | ---------------------------------------------------------------------------------------------------------------------------- | | 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. {% stepper %} {% step %} **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. {% endstep %} {% step %} **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: | Deployment | Configuration Directory Path | | ---------- | ----------------------------------- | | 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. {% hint style="info" %} 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. {% endhint %} {% endstep %} {% endstepper %} ### 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. {% stepper %} {% step %} **Stop the Primary ZigiOps server** {% endstep %} {% step %} **Copy the runtime files from the Primary to the Backup server** The runtime file paths are: | Deployment | Runtime Files Path | | ------------- | ---------------------------------------------------- | | Windows | C:\ZigiWave\ZigiOps\platform\conf\settings\runtime | | Linux | /opt/zigiwave/zigiops/platform/conf/settings/runtime | | Docker | platform volume: /conf | | {% endstep %} | | {% step %} **Start ZigiOps on the Backup server** {% endstep %} {% endstepper %} {% hint style="info" %} 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. {% endhint %} ### 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: | Parameter | Value | | -------------- | ------------------------------------------------------------------------------------ | | 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 {% stepper %} {% step %} **Stop the Primary ZigiOps server** {% endstep %} {% step %} **Start the Backup ZigiOps server** {% endstep %} {% endstepper %} 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. {% hint style="info" %} 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. {% endhint %} ### 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 --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://docs.zigiwave.com/operations-and-monitoring/scaling-and-load.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.