Why Hardware Sizing Matters for On-Premise Bitrix24
Bitrix24's self-hosted edition is not a lightweight app. It runs a full-stack web environment — nginx as a reverse proxy, Apache handling dynamic requests, PHP-FPM, and a Percona/MySQL database. Add push-and-pull for real-time chat, background cron jobs, and optional integrations (telephony, ERP, e-signature), and the resource footprint grows quickly.
Under-provisioning shows up as slow page loads, failed background tasks, and database lock timeouts. Over-provisioning wastes budget. The reference profiles below aim for the sweet spot based on production audit data from our project archive.
Key principle: Size for concurrent users, not registered users. In most organisations, 20–30 % of registered users are active simultaneously during peak hours.
Software Stack: What Bitrix24 Actually Needs
Before looking at hardware numbers, understand what the server runs. The recommended web environment for the current Bitrix24 on-premise release is:
| Component | Minimum supported | Recommended |
|---|---|---|
| Operating System | CentOS Stream 8 / Ubuntu 22.04 | CentOS Stream 9 / Ubuntu 24.04 |
| Reverse proxy | nginx 1.20+ | nginx 1.26+ |
| Web server | Apache 2.4.40+ | Apache 2.4.62+ |
| PHP interpreter | PHP 8.1 | PHP 8.2+ |
| Database | Percona Server 5.7 / MySQL 5.7 | Percona Server 8.0+ |
From our audit of a mid-size production portal (≈100 active users), the server ran on an outdated web environment — nginx 1.20, Apache 2.4.6, PHP 8.1, and Percona 5.7 — which the platform's own health check flagged as problematic. Upgrading the full stack, including the OS, resolved several stability warnings and closed security gaps.
Deployment tip: Use the official Bitrix24 virtual machine image for initial setup. It ships with a pre-tuned web environment and cuts provisioning time significantly. If you host on a customer-provided server, request root SSH access and both ports 80 and 443 before the deployment session.
Hardware Profiles by User Count
The table below represents the minimum production-grade specifications. "Test/demo" environments can be smaller, but should never be used as a migration target for real user data.
| Tier | Registered users | Est. concurrent | CPU cores | RAM | SSD storage | Notes |
|---|---|---|---|---|---|---|
| Small | up to 50 | 10–15 | 4 cores | 8 GB | 100 GB | Single-server, all components co-located |
| Medium | up to 100 | 20–30 | 8 cores | 16 GB | 200 GB | Single-server or split DB |
| Large | up to 500 | 80–150 | 16 cores | 48–64 GB | 500 GB + object storage | Separate DB server recommended |
| Enterprise | 1,000+ | 250–400 | 32+ cores | 96–128 GB | 1 TB+ with tiered storage | Multi-server cluster, dedicated push server |
From a real production audit of a portal used by approximately 100 concurrent users: the server ran 16 CPU cores and 47 GB RAM, and the system health check rated both as excellent. The database at that time was ~28 GB — described as normal for a mid-size portal. These real-world numbers validate the "Large" tier in the table above and confirm that a 100-user box can be run on a single well-provisioned server if the database size stays below ~50 GB.
Database Sizing and Tuning
The database is the most common performance bottleneck in self-hosted Bitrix24 deployments. Key InnoDB parameters need manual adjustment — the defaults shipped with most OS packages are not suited for a busy portal.
Settings to tune at deployment:
innodb_log_file_size— increase from the default 64 MB to at least 512 MB for medium portals, 1–2 GB for large ones. A 64 MB value is flagged as undersized by the platform's own health check.query_cache— disable. Query cache causes contention under concurrent writes and has been removed in MySQL 8.0 entirely. Leaving it enabled on MySQL 5.7/Percona 5.7 degrades performance.local_infile— disable for security. This option allows file imports from the MySQL client and is a known attack surface.join_buffer_size/sort_buffer_size— 32 MB each is the common production value; tune upwards only if slow query logs show sort/join spills.
Database growth estimates:
| User tier | DB size at go-live | DB size after 2 years (typical) |
|---|---|---|
| 50 users | 2–5 GB | 8–15 GB |
| 100 users | 5–15 GB | 20–40 GB |
| 500 users | 15–50 GB | 80–150 GB |
| 1,000+ users | 50–100 GB | 200 GB+ |
Plan storage with a 3× headroom over current DB size, and implement daily backups to a separate volume or remote location. Backup jobs should cover both the database dump and the /home/bitrix/www/ file tree.
Network and Storage Architecture
The diagram below shows the component layout for a medium-to-large self-hosted Bitrix24 deployment. For small (≤50 users) installations all components sit on a single server; for 500+ users, separating the database and file storage reduces I/O contention on the application server.
The diagram illustrates how users reach Bitrix24 through nginx (reverse proxy), which routes static assets from disk and forwards dynamic requests to Apache/PHP-FPM. The database runs on Percona Server, optionally on a dedicated host, while backups and large file storage go to an external volume or object storage bucket.
flowchart LR
USERS[Users / Browsers] --> NGINX[nginx\nReverse Proxy]
NGINX --> STATIC[Static Files\n/home/bitrix/www]
NGINX --> APACHE[Apache + PHP-FPM\nDynamic Requests]
APACHE --> DB[(Percona Server\nMySQL)]
APACHE --> PUSH[Push & Pull Server\nReal-time Chat]
DB --> BACKUP[Backup Storage\nRemote / S3]
APACHE --> FILES[File Storage\nDisk / Object Store]
Disk I/O notes:
- Use SSD or NVMe for the database data directory. Spinning disks cause severe latency under concurrent write loads.
- Separate the database data directory (/var/lib/mysql) onto its own volume to avoid contention with application logs and uploaded files.
- For portals with heavy file sharing, consider object-compatible storage (e.g., MinIO or a cloud bucket) mounted as the Bitrix24 disk module backend.
Networking:
- The portal needs outbound SMTP access for system notifications. Configure a dedicated transactional mail account (SMTP, port 587, TLS) — do not rely on the OS sendmail binary.
- Push-and-pull for real-time chat requires a persistent WebSocket connection; ensure your firewall and load balancer pass WebSocket upgrade headers.
- For remote-access deployments, restrict the admin panel (/bitrix/admin/) to a specific IP allowlist at the nginx level.
SSL, Security Hardening, and Post-Install Checklist
Hardware sizing is only part of the story. A production on-premise Bitrix24 installation also needs a security baseline before it goes live. The following checklist is drawn from security audit findings on live portals:
Critical (do before go-live):
- [ ] Issue and configure an SSL certificate (Let's Encrypt works well for internet-facing portals); enable HTTP → HTTPS redirect.
- [ ] Add an HSTS header at the nginx/Apache level.
- [ ] Disable PHP error display (display_errors, display_startup_errors → Off in php.ini). Leaving these on exposes file paths, SQL queries, and stack traces to end users.
- [ ] Disable local_infile in MySQL/Percona.
- [ ] Enable two-factor authentication (2FA) for all admin accounts via Bitrix24's built-in OTP module.
- [ ] Restrict admin panel access to a defined IP range.
High priority (within first week): - [ ] Run the platform's built-in database structure check; fix all auto-correctable errors and manually review remaining ones. - [ ] Configure firewall rules; maintain a blocklist of IPs with repeated brute-force or injection attempts. - [ ] Enable frame-busting protection in Bitrix24 security settings. - [ ] Enable the built-in web antivirus (note: activating it adds a small CPU overhead — test under load before enabling in production).
Ongoing: - [ ] Keep the web environment (OS, nginx, Apache, PHP, Percona) up to date. Outdated stacks — even minor version lags — are the single most common finding in our portal audits. - [ ] After any update, run the platform's "System Check" tool to catch version mismatches and configuration drift. - [ ] Document and audit any core file modifications. In one production portal we audited, 23 out of 109,188 files had been modified (0.02% modification rate). That level is manageable, but undocumented changes block safe updates.
For a deeper look at what the on-premise edition offers compared to cloud, see Self-Hosted CRM: Why Choose Bitrix24 On-Premise for Data Sovereignty.
Cloud-to-On-Premise Migration: Server Readiness
Many deployments begin as cloud portals and later migrate to self-hosted — either for data sovereignty, cost control at scale, or compliance requirements. Before migration starts, the target server must satisfy all hardware specs for the expected user tier, and the following must be ready:
- SSH root access for the implementation partner.
- Open ports 80 and 443 (HTTP/HTTPS) accessible from the internet or internal network as required.
- DNS record pointing the subdomain (e.g.,
crm.yourdomain.com) to the server's public IP — this needs to be done before SSL issuance. - SMTP credentials for system notification emails (invitations, password resets, task alerts).
- Backup volume separate from the main OS disk.
The deployment work itself — environment provisioning, license key registration, push-and-pull setup, SSL, test user creation, module cleanup, and backup configuration — typically takes around 7 hours of engineer time on a prepared server.
If you are planning to move from a cloud CRM to a self-hosted Bitrix24, the data architecture considerations in our HubSpot to Bitrix24 migration guide apply to the data-mapping phase regardless of the source platform.
Estimating Total Cost of Ownership
Hardware is only one line in the TCO calculation. For reference, a self-hosted Bitrix24 deployment in the 50-user tier involves:
- License — the on-premise Corporate Portal licence for 50 users is a one-time purchase with annual renewal at approximately 25–30% of the original licence fee. Exact pricing in USD/AED depends on region and your reseller agreement.
- Server — a cloud VPS meeting the "Small" tier specs above costs roughly $30–80/month depending on provider and region, or a one-time capex for bare-metal hardware.
- Implementation — setup, configuration, and user onboarding typically runs 4–7 weeks for a 50–100 user deployment. See Bitrix24 Implementation Cost & Timeline: Real Data from 1,300+ Projects for a full breakdown.
- Annual maintenance — OS patching, module updates, and periodic security audits. Budget for at least one audit cycle per year; findings in production portals consistently show that unpatched environments accumulate high-priority risks within 18–24 months.
Before committing to on-premise, it is worth reviewing the Bitrix24 vs HubSpot comparison if you are evaluating cloud alternatives alongside self-hosted options.
Updating a Live On-Premise Installation
Module and core updates on a production self-hosted portal require a structured process — pushing updates directly to a live server with active users is the most common cause of post-update incidents. The safe update workflow:
- Take a full backup: database dump + all files + configuration files.
- Spin up a test server and restore the backup there.
- Move any custom code from
/bitrix/php_interface/to/local/(the correct location for customisations that survive updates). - Apply the update on the test server; verify all critical functionality: CRM entities, tasks, business processes, third-party integrations (telephony, ERP).
- Only after successful test validation, apply the same update to production.
- Run the platform health check immediately after the production update.
This process adds 1–2 days to the update cycle but prevents the far more expensive recovery from a botched live update.
For teams running AI-powered call analysis or other compute-intensive add-ons, test those workloads specifically on the staging server during step 4 — they are disproportionately sensitive to PHP version changes.