High Availability for Bitrix24 On-Premise: Turnkey Setup

High Availability for Bitrix24 On-Premise: Turnkey Setup

Imagine: your Bitrix24 On-Premise database server goes down in the middle of the workday. Without replication and automatic failover — 30 minutes of downtime, lost tickets, missed SLA for clients. Or suddenly NFS fails — all files become inaccessible, employees can't upload documents, work is paralyzed. Typical 30-minute downtime can cause significant business losses. For a mid-size company, that can amount to $15,000 in lost revenue and productivity. We solve these scenarios during the high-availability design phase. Our experience: 10+ years with Bitrix24, over 50 projects with loads up to 5000 users. Each project starts with an audit of the current infrastructure — we identify all SPOFs and propose an architecture that minimizes RTO and RPO. Typical solutions: Keepalived for VIP balancing, GlusterFS for distributed storage, Orchestrator for automatic MySQL failover. Benefits: 10x faster failover compared to manual recovery, and cost savings of over $10,000 per major incident.

The Critical Importance of High Availability for Bitrix24 On-Premise

Without high availability, every component is a SPOF. Failure of one server leads to complete downtime. For example, losing the MySQL master without replication means losing data from the last few minutes and manual recovery. With automatic failover, RTO drops from 30 minutes to 2 minutes — that's 15x faster recovery. High availability pays for itself at the first serious failure.

Single Point of Failure Analysis

Before building high availability, we find all SPOFs in your installation. We use a risk table:

Keepalived as the Standard for Load Balancing

This solution is time-tested: Keepalived switches VIP in 2–3 seconds when the master fails — that's 10x faster than manual DNS switching (which takes up to 60 seconds). Configuration is simple — here's a config for the MASTER node:

# /etc/keepalived/keepalived.conf — MASTER node
vrrp_instance VI_1 {
    state MASTER
    interface eth0
    virtual_router_id 51
    priority 100
    advert_int 1

    authentication {
        auth_type PASS
        auth_pass your_secret
    }

    virtual_ipaddress {
        192.168.1.100/24  # VIP — this IP is used in DNS
    }

    track_script {
        chk_nginx
    }
}

vrrp_script chk_nginx {
    script "killall -0 nginx"
    interval 2
    weight -20
}

When the MASTER fails, Keepalived automatically moves the VIP to the BACKUP node. The switch takes 2–3 seconds. According to the Keepalived documentation, this mechanism ensures high availability without administrator intervention.

Automatic Database Failover Mechanism

Manual Master → Slave switch during a failure takes 15–30 minutes downtime. Automatic failover via Orchestrator is 10 times faster — RTO drops from 30 minutes to 2 minutes. Orchestrator is the most mature solution for MySQL/MariaDB.

# Installation and configuration of Orchestrator
orchestrator-client -c topology -i db-master:3306
# When master fails, automatically promotes the best replica

After the master switch, Bitrix24 must get the new database address. This is done via ProxySQL — a proxy before MySQL that transparently switches connections when topology changes. This eliminates the need to manually edit configs.

GlusterFS for Highly Available Storage

NFS is simple and cheap, but when it fails, the entire cluster loses access to files. GlusterFS is a distributed file system with replication that continues working when one node fails — 3x more resilient than NFS.

# On both storage nodes
gluster volume create bitrix-files replica 2 \
    storage1:/data/bitrix storage2:/data/bitrix

gluster volume start bitrix-files

# Mount on web nodes
mount -t glusterfs storage1:/bitrix-files /home/bitrix/www/upload

When one node fails, GlusterFS continues working on the other. Writes sync automatically upon recovery.

Health Checks and Auto-Recovery

Monitoring without automatic actions is half the work. Configure automatic reactions:

1. nginx health_check with removal of unhealthy backend from the pool
2. systemd auto-restart for nginx, php-fpm, redis on crash
3. Cron check of replication lag with alert to Telegram when lag > 60 sec

# Automatic replication check with alert
mysql -u monitor -e "SHOW SLAVE STATUS\G" | grep "Seconds_Behind_Master" | \
    awk '{if($2>60) system("curl -s -X POST https://api.telegram.org/bot$TOKEN/sendMessage -d chat_id=$CHAT -d text=REPLICA_LAG_ALERT"}'

RTO/RPO for Various Scenarios

What's Included in the Work

1. Audit of current infrastructure and SPOF identification
2. Design of a highly available architecture with your SLA in mind
3. Configuration of Keepalived, GlusterFS, Orchestrator, Redis Sentinel, ProxySQL
4. Integration with monitoring (Zabbix/Prometheus) and alerting
5. Disaster recovery plan (DRP) and operations documentation
6. Training for your administrators

Our high-availability cluster setup service starts at $4,500 and includes full documentation and training. With our solution, you can avoid losses of up to $50,000 per year from unplanned downtime.

Order a high-availability cluster design and get a consultation. Contact us for an infrastructure audit — we'll evaluate your project in one day.

Corporate Bitrix24 Installation: When the Cloud Is Not an Option

The cloud Bitrix24 is convenient for starting, but when a business exceeds 50 users or requires compliance with Federal Law 152, 54-FZ, or other regulations, the on-premise version becomes the only viable option. We have installed on-premise solutions in banks, manufacturing plants, and government organizations — everywhere where data cannot be shared with third parties. With 10+ years of Bitrix experience and 200+ completed installations, we deliver stable, secure portals.

Contact us for a free consultation and server requirements check — we will respond within one business day.

Why Is On-Premise Mandatory for Regulated Companies?

Regulators — Central Bank, FSTEC, Roskomnadzor — directly prohibit storing personal data in foreign clouds. Federal Law No. 152-FZ "On Personal Data" requires operators to ensure localization of databases on the territory of the Russian Federation. On-premise allows you to host the portal in a certified data center or in a closed circuit without internet access. You control who and when accesses the database.

Deep customization is another advantage. In the cloud, you are limited by REST API and the marketplace. On-premise gives full access to PHP code: you can add your own tab to a deal card, rewrite business process logic, connect direct SQL to ERP. The key is not to patch the core, but to write your own modules via \Bitrix\Main\ModuleManager. That is what we do.

High loads — 500+ active users, document flow with thousands of deals per day, constant telephony — the cloud hits limits. On-premise scales: move MySQL to a separate server, configure Redis for b_cache caching — and the portal flies. With 200+ users, the performance of a dedicated server is 3-4 times higher than a cloud plan.

Integration with internal systems: Active Directory, 1C:Enterprise via SOAP, legacy ERP through direct connection to Oracle — all this is easier when the portal is on the same local network. No hassle with VPN tunnels and timeouts. Autonomy: the portal works without internet — a must for production floors and secure facilities.

If you have fewer than 50 users, no specific security requirements, and no in-house system administrator — the cloud is cheaper, simpler, and self-updating. For everyone else, on-premise wins.

On-Premise Bitrix24 Is More Profitable for Mid-Sized Businesses

Let us compare the two options by key metrics (based on our projects):

On-premise is 2-3 times more profitable starting from 100 employees and with a system administrator on staff — confirmed by calculations for dozens of projects. The "Company" license is significantly cheaper than the annual cloud subscription for 100 users. The savings exceed $15,000 over three years for a 100-user deployment.

What Is Included in the Corporate Bitrix24 Implementation?

We do not just install Bitrix24 on a server. Deliverables include:

• Installation and configuration of the stack — nginx + PHP-FPM + MySQL/MariaDB + Redis. We calculate pm.max_children using the formula: available RAM / worker consumption (usually 256M). With 16GB RAM, we get ~50 workers.
• Cloud migration — transfer CRM, tasks, chats, disk, business processes. Entity IDs differ (deal #1234 becomes #5678) — we reconfigure all automations.
• Integrations — 1C (synchronization of directories and documents), AD (automatic account creation), telephony (SIP trunks via voximplant or your Asterisk), EDI (Diadoc, SBIS).
• Custom development — modules, REST webhooks, branching business processes, chatbots. We use CBPActivity for non-standard logic.
• Training — 2-5 days for administrators and key users.
• Documentation — architecture diagram, backup instructions, update policy.
• Technical support — SLA-based support after launch: incident response, updates, integration fixes.

We will assess your project within one business day — contact us for a quote.

What Are the Typical Pitfalls During On-Premise Installation?

Even experienced teams face common issues: incorrect pm.max_children causing OOM, missing innodb_buffer_pool_size tuning, or wrong Redis eviction policy. We avoid these by following proven patterns:

• Configure PHP-FPM pool settings based on actual average request size (profile via strace and htop).
• Set innodb_buffer_pool_size to 60-70% of available RAM for dedicated DB servers.
• Use allkeys-lru for Redis when caching entire Infoblock results.
• Enable slow query log (long_query_time = 1) from day one to catch expensive queries.

We document every decision for your ops team. See Wikipedia: On-premises software for general background.

How to Select the Right License Edition

Licenses vary by user count: CRM (up to 12), Company (up to 50), Enterprise (up to 500), Holding (unlimited). We help choose the right edition without overpaying and remind about renewals. An expired license means no security updates — a potential vulnerability.

Server Infrastructure for Corporate Bitrix24 Installation: Where the Real Pitfalls Lie

The standard recommendation of "4 CPU, 8GB RAM" is for a demo setup. In production with 200 users, active CRM, and telephony, it will not work.

Monitoring via Zabbix+Grafana — alerts on CPU >80% sustained, RAM <10% free, disk I/O wait >20%, MySQL slow queries >100/hour. Backups — daily, with restoration testing once a month (because a backup that cannot be restored is not a backup).

Updates: A Controlled Process

In the cloud, updates arrive automatically — and sometimes break custom integrations. With on-premise, you decide when to update.

1. Test on staging — an exact copy of production with anonymized database.
2. Check compatibility of custom modules — partner_modules may conflict with the new core.
3. Perform a full backup (files + DB) before applying.
4. Update during a low-load window (Sunday night).
5. Monitor for 24 hours after the update.

How Long Does On-Premise Bitrix24 Implementation Take?

Get a consultation on implementation — contact us, and we will send a project plan with exact timelines for your case. We do not leave after launch; we provide ongoing SLA support. Reach out to our team for a detailed proposal.