ZBIX CRM 1.2.0

Plan capacity for CRM workloads

Product Zbix CRM · Version 1.2.0 · Source reviewed · Reviewed 28 October 2026
Audience Administrators and implementation teams · Deployment Release specific self hosted

Overview

Initial installation capacity and sustained operating capacity are different. Imports, recurring billing, document generation, reporting, automation and encrypted backups can overlap and increase memory, CPU and disk demand after an otherwise healthy installation.

Purpose

Set a measured resource plan and growth thresholds for the expected users, records, private files and background work.

Prerequisites

Expected user concurrency, record volume, import sizes and file-retention requirements.
A selected platform and an isolated representative test environment.
Monitoring for host capacity, service health and background queues.

Procedure

Start from the package-specific installation requirements. For Linux the documented low-volume floor is two vCPU, 8 GiB advertised RAM and 20 GiB free disk before loading images. Do not apply those figures as a verified Windows minimum.
Estimate database and private-file growth separately. Include import sources, generated PDFs, logs, temporary backup staging and retained encrypted recovery points.
For heavier Linux work, evaluate the documented planning target of four vCPU and 8–16 GiB RAM. Maintain at least 25 percent steady-state memory headroom and test the periods when background activities overlap.
Rehearse representative imports, reports, automation and backup/restore tests in isolation. Record duration, queue delay, peak memory, disk growth, restarts and out-of-memory events.
On burstable cloud instances, monitor CPU-credit behavior as well as CPU percentage. Review storage performance and available space before increasing concurrent workloads.
Set operational thresholds and review them after significant data growth, new integrations or changed backup retention. Approve scaling based on measured results rather than an idle dashboard.

Expected result

The team has a workload-specific resource baseline and capacity triggers tied to observed behavior.

Important notes

The four Linux service memory ceilings total approximately 4.75 GiB; host services and short-lived migration or recovery work also consume resources.
The v2 encrypted backup format is memory-bound and defaults to a 1 GiB bundle limit. Large installations require explicit backup capacity qualification.
No universal maximum-user, throughput, latency, RPO or RTO guarantee is established by the reviewed evidence.

Troubleshooting

If jobs accumulate while the API remains ready, examine worker heartbeat, due-work age, queue failures and resource saturation.
If a backup exceeds its configured bound, preserve the last verified recovery point and have the recovery owner review capacity and the supported backup approach.
Escalate recurring out-of-memory events or repeated service restarts with a sanitized time series and workload description.

Download manuals ↓

Need a hand?

Search the guides or talk to the ZBIX team.

Find support