Self-Hosted Bitrix24 Hardware Sizing Guide: 50 to 1,000+ Users

Why sizing matters more in self-hosted

In self-hosted Bitrix24 (Alaio), incorrect sizing is the leading cause of failures: underpowered servers cause automation timeouts and real-time chat outages, while the most common issues found in real-world deployments stem from misconfigured database parameters, outdated PHP versions, and the absence of service separation.

In the cloud edition, Bitrix24 manages the infrastructure for you. In the on-premise edition, that responsibility falls entirely on you - or your implementation partner. An underpowered server produces slow CRM performance, automation timeouts, and Push & Pull failures (real-time chat). An oversized server wastes budget.

Based on our experience across deployment projects, the most frequent problems are not caused by purchasing the wrong hardware, but by:

• Misconfigured database parameters - for example, innodb_log_file_size set too low, or Query Cache left enabled unnecessarily
• Outdated web environment - older versions of PHP, nginx, or MySQL introduce bottlenecks and security vulnerabilities
• No service separation - database, application, and file storage all sharing the same disk

Before provisioning any machine, define three variables: the number of concurrent users (not just registered users), the estimated data volume (CRM plus files), and whether high availability is required.

Requirements by user range

The requirements table shows, for example, that portals with up to 50 users need 4 vCPUs and 8 GB of RAM, while portals with 501-1,000 users require 32+ vCPUs, 96-128 GB of RAM, and NVMe disks in RAID 10 - figures validated by real production data.

The table below reflects typical usage profiles: active CRM, tasks, chat, and at least one integration (telephony or ERP). Users who rely solely on the internal communication portal may reduce these figures by approximately 20%.

Project reference: a production portal with approximately 150 active users runs stably on 16 vCPUs and 47 GB of RAM, with a database of approximately 28 GB - figures that align with the 100-250 user range in the table above.

System software: recommended versions

The currently recommended stack is Ubuntu 24.04, nginx 1.26+, PHP 8.2+, and Percona Server 8.0.41+; using the vendor's official virtual machine image is the safest way to guarantee this environment without configuration conflicts.

The web environment is just as important as the hardware. Running older versions of PHP or MySQL creates bottlenecks and security gaps. The table below lists the currently recommended stack:

The safest way to ensure the correct stack is to use the official virtual machine image provided by the Bitrix24 vendor, always in the latest available version. This eliminates configuration conflicts and simplifies future updates.

Critical MySQL/Percona parameters

For portals with 100-500 users, critical MySQL parameters include setting innodb_buffer_pool_size to 70% of RAM, innodb_log_file_size to 512 MB, disabling Query Cache, and setting local_infile = 0 - errors in these settings are the most recurring cause of slowness found during audits.

Adequate hardware alone will not solve performance problems if the database is misconfigured. In audits of underperforming portals, we repeatedly encounter the same mistakes:

• innodb_log_file_size set to 64 MB (the default) - for medium and large portals, the recommended value is between 256 MB and 1 GB
• query_cache_type = ON - Query Cache is deprecated in MySQL 8.x and must be disabled
• local_infile = ON - this poses a security risk and must be disabled
• join_buffer_size and sort_buffer_size at 32 MB or less - adjust these according to your workload

Reference parameters for a portal with 100-500 users:

innodb_buffer_pool_size = 70% da RAM disponível para o BD
innodb_log_file_size = 512M
query_cache_type = 0
query_cache_size = 0
local_infile = 0
join_buffer_size = 8M
sort_buffer_size = 4M

Recommended architecture by user range

The architecture evolves across 4 stages: single server up to 100 users, database separation up to 250, dedicated storage up to 500, and a load balancer with Master-Replica DB for 500-1,000 users - from 250 users onward, separating services is the first mandatory step.

The architecture evolves as the user count grows. For small portals, a single server covers everything. From approximately 250 users onward, separating services is the first step toward improved performance and resilience.

The typical progression is: single server - database separation - cluster with read replica - full high availability with load balancer.

flowchart TD
    A["50-100 usuários\nServidor único\n(App + BD + Arquivos)"] --> B["100-250 usuários\nApp Server separado\ndo Banco de Dados"]
    B --> C["250-500 usuários\nApp Server + BD dedicado\n+ Storage NFS/NVMe separado"]
    C --> D["500-1.000 usuários\nBalanceador + 2 App Servers\n+ BD Master-Réplica\n+ Storage dedicado"]

For installations above 500 users, also consider separating the Push & Pull server - which handles real-time chat and notifications - since it generates a persistent connection load that is independent of the CRM workload.

For details on active-passive clustering and database replication, see the guide Bitrix24 Self-Hosted High Availability: Master-Replica Cluster Setup.

Storage: types, sizing, and growth

Database storage grows at 1-5 GB per month and telephony recordings alone can reach hundreds of GB per year; the recommendation is to use NVMe for the database above 100 users, separate volumes, and plan for expansion at least 6 months in advance.

Disk is often the forgotten bottleneck. Self-hosted Bitrix24 stores:

• MySQL database - grows approximately 1-5 GB per month on active portals with heavy CRM use
• User files (Drive, attachments, call recordings) - the largest consumer; a single telephony integration can generate hundreds of GB per year
• Local backups - ideally stored on a separate volume or external storage

Practical recommendations:

1. Use NVMe SSD for the database at any user range above 100 users
2. Keep the data volume separate from the operating system volume
3. Monitor monthly growth and plan for expansion at least 6 months in advance
4. Configure automatic backups - for both the database and files - to a destination separate from the production server

Read more about a complete backup strategy in On-Premise Bitrix24: Backup & Disaster Recovery Strategy.

Physical servers vs. VPS vs. private cloud

There is no single ideal model: physical servers are best suited for 500+ users with sensitive data, dedicated VPS works well for 50-250 users with low CAPEX, and public cloud offers elasticity at any scale provided a DevOps team is available.

There is no single right answer - it depends on budget, data sovereignty requirements, and internal technical capability.

For public cloud deployments, see Deploying Self-Hosted Bitrix24 on AWS, Azure, or a Private Cloud.

Pre-provisioning checklist

The 9-item pre-provisioning checklist covers everything from defining concurrent users and modules to configuring backups on the first day of production - every item must be validated before any hardware order or instance is created.

Use this checklist before placing any hardware order or creating any instance:

• Number of registered and estimated concurrent users defined
• Modules to be used listed (CRM, Drive, telephony, intranet, tasks)
• Initial data volume and estimated growth rate defined
• High availability requirement defined (required SLA)
• Storage type selected (SSD/NVMe for DB, HDD for cold backups)
• Software stack aligned with the current Bitrix web environment version
• Root SSH access available to the implementation partner during deployment
• Ports 80 and 443 open, and domain/DNS configured before installation begins
• Initial automated backup configured on the first day of production

For a total cost of ownership analysis comparing self-hosted with the cloud edition, see Self-Hosted vs Cloud Bitrix24: Complete 3-Year TCO Analysis.

Working with a partner for self-hosting. Want the control of self-hosted Bitrix24 without managing the server yourself? ACP Group deploys and operates it for you - see Bitrix24 self-hosted gerenciado, planos de suporte e manutencao, or request a orcamento chave na mao.