Bitrix24 On-Premise Deployment Services

Bitrix24 On-Premise: When the Cloud Isn't an Option

On-premise means the code is on your server, the data is in your database, and you install updates when you want — not when 1C-Bitrix decides. Full control, full responsibility.

Five Reasons to Choose On-Premise (and One Not To)

Security and compliance. Banks, government agencies, healthcare, defense — anyone whose regulator prohibits storing data in someone else's cloud. Federal data protection laws, financial sector security standards, regulatory requirements — on-premise allows deploying the portal in a certified data center or even in a closed network without internet access.

Deep customization. The cloud is limited to the marketplace and REST API. On-premise means full access to PHP code. Want to rewrite the deal card logic? Add a tab with ERP data via direct SQL? Embed a custom widget in the task kanban? In the cloud — you can't. On-premise — bitrix/modules/crm/lib/ is open for reading and modification (through custom modules, not core patches).

High loads. 500+ users, active document flow, CRM with thousands of deals per day, telephony — the cloud hits its limits. On-premise scales: add RAM, move MySQL to a separate server, configure Redis for b_cache caching — and the portal breathes.

Integration with internal systems. Active Directory, 1C:Enterprise via SOAP, legacy ERP through direct connection to Oracle/MSSQL — all of this is easier when the portal is on the same network. No need to set up VPN tunnels and deal with timeouts.

Autonomy. The portal works without internet — on the local network. For manufacturing facilities and restricted-access sites — a requirement, not a whim.

When not to choose: if you have fewer than 50 users, no special security requirements, and no in-house sysadmin. The cloud is cheaper, simpler, and updates automatically.

What We Do with On-Premise

Stack installation and configuration. Not "installed from the box and left," but a carefully tuned configuration:

• Server configuration matched to actual load — not from marketing tables, but from profiling
• nginx + PHP-FPM + MySQL/MariaDB. pm.max_children calculated by formula: available RAM / consumption per worker. Set 256M per worker — with 16GB RAM you get ~50 workers, minus OS and MySQL
• .settings.php — Redis for sessions and cache (cache → redis, session → redis). Without this, the Push & Pull module will lag
• SSL, DNS, mail server. Push server push-server on Node.js — without it, no real-time notifications
• LDAP/Active Directory — single authentication point. Terminated an employee in AD — they automatically lose portal access

Migration from cloud. We transfer everything:

• CRM: leads, deals, contacts, companies, activity history
• Company structure, departments, users with permissions
• Tasks, projects, kanban boards, comments
• Chats, drive files
• Business processes and CRM robots
• Telephony and open channels

The main migration trap — entity IDs don't match. Deal #1234 in the cloud becomes #5678 on-premise. All automations tied to specific IDs (and they're always tied) need to be reconfigured.

Custom development:

• Custom modules via \Bitrix\Main\ModuleManager — not core patches, but proper modules with install/uninstall
• REST applications and webhooks
• CRM modifications: custom fields, tabs, card actions
• Business processes with branching, conditions, and integrations — the built-in BP designer covers 70%, the rest we code via CBPActivity
• Chatbots for internal processes — via Bitrix\ImBot

Integrations:

• 1C — synchronization of directories, documents, settlements. Via the standard module or custom exchange over REST
• Active Directory — auto-creation and blocking of accounts via LDAP connector
• IP telephony — SIP trunks, routing via voximplant or your own Asterisk
• Email — Exchange, Postfix. IMAP connector for incoming, SMTP for outgoing
• EDI — Diadoc, SBIS via API

Server Infrastructure: Where the Real Pitfalls Are

The standard recommendation of "4 CPU, 8GB RAM" is for a demo stand. In production with 200 users, active CRM, and telephony, it won't survive.

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 restore verification once a month. Because a backup that can't be restored isn't a backup.

Updates: A Controlled Process

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

• Test on staging — an exact copy of production with an anonymized database
• Check compatibility of custom modules — partner_modules may conflict with the new core
• Full backup (files + DB) before applying
• Update during a low-traffic window — Sunday night
• Monitor for 24 hours after the update

Licenses

• CRM — up to 12 users
• Company — up to 50
• Enterprise — up to 500
• Holding — no limit

We help choose the edition, handle licensing, and send renewal reminders. An expired license = no security updates = a potential vulnerability.

Timelines

Full cycle — from edition selection to ongoing support. We don't leave after deployment.