Customizing Beyond Cloud Limits: What Becomes Possible with Self-Hosted Bitrix24

Why Cloud Has a Ceiling - and Self-Hosted Does Not

In the cloud version of Bitrix24 (Alaio), you operate within a shared environment managed by the vendor. This brings automatic security updates and maintenance, but it also means that the boundaries of what you can modify are defined by Bitrix, not by your organization. REST APIs, webhooks, and Marketplace applications are the only available extension points.

With the self-hosted (on-premise) version, the equation changes entirely. You install the product on your own server, have SSH access to the file system, and can - within the terms of the license - modify PHP files, JavaScript, and templates directly in the platform core. This level of access opens up an entirely different category of customization, and it is particularly relevant for product owners and IT directors who need to fit Bitrix24 into complex enterprise architectures.

Important: Access to the source code does not mean "change anything without consequences." Poorly documented modifications create technical debt and can block future updates. The sections below cover what to modify, how to do it safely, and where the practical limits lie.

---

What You Can Modify in the Source Code

In Bitrix24 self-hosted, every layer of the application is available for modification - PHP, JavaScript, templates, and components. In practice, however, real projects show that fewer than 25 files (roughly 0.02% of a codebase of approximately 109,000 files) are typically changed during the first development cycles.

Bitrix24 self-hosted is structured around independent modules - CRM, tasks, internal messenger, corporate social network, localization, extranet, and others. With server access, you can intervene at any layer:

Layer	Examples of modification
PHP / business logic	Custom fields on CRM entities, address types, requisite rules
JavaScript / frontend	Chat behavior, recent contacts list, map widgets
Component templates	Gantt layout, voting screens, extranet pages
Proprietary components	Creating entirely new components (vendor:component.name)
Additional modules	Selective installation or removal of modules; only required modules remain active

Based on real implementation projects, a typical self-hosted installation with moderate customization sees approximately 0.02% of files modified - meaning that in a codebase of roughly 109,000 files, fewer than 25 are usually changed during the first development cycles. This confirms that surgical customization is sufficient to meet the vast majority of business requirements.

---

The Most Common Customizations in Real Projects

In self-hosted implementations, the most frequent patterns involve CRM, messaging, tasks, and localization - from custom fields in crm_fields.php and color-coded Gantt views by deadline, to replacing the map widget and creating components with a proprietary namespace that sits outside the core update scope.

Based on our implementation experience, the most common customization patterns in self-hosted deployments are:

CRM Module

• Adding custom fields and address types directly in crm_fields.php and entityaddresstype.php
• Building custom requisite logic for entities (entityrequisite.php)
• Developing event handlers for specific processes - for example, automatically associating approved suppliers with a purchase record at the end of a smart process

Messaging Module

• Modifying internal chat templates to display additional user information
• Adjusting the messenger JavaScript bundle for custom behavior in the recent conversations list

Tasks Module

• Visual customization of the Gantt chart (tasks.task.gantt) for color-coded indicators by deadline and status - a feature that does not exist natively and requires dedicated development
• Advanced filters and exports for task lists

Localization Module

• Replacing the default map widget with alternative providers (for example, integrating regional map services)
• Configuring address pop-ups with behavior adapted to the local sales workflow

Entirely New Components

You can create custom components with a dedicated namespace (for example, yourvendor:field.period). These components fall outside the Bitrix24 core update scope and can be versioned separately in your own Git repository.

---

Integrations That Are Only Possible in Self-Hosted

The self-hosted edition retains all REST/webhook integrations available in the cloud and adds 4 exclusive categories: direct database access, OS-level SSO authentication, message queues via RabbitMQ/Kafka in PHP handlers, and connections to legacy systems without a REST API via server-side cron jobs.

The cloud version supports integration via REST API and webhooks. Self-hosted keeps those options and adds:

• Direct database integration: queries and synchronizations that bypass the API layer, useful for batch data operations (for example, syncing with an ERP twice daily - morning and end of business)
• Active Directory / LDAP at the operating system level: beyond Bitrix24's native integration, you can configure SSO authentication directly at the web server level
• Internal message queues: integration with messaging systems (RabbitMQ, Kafka) directly through PHP code in event handlers
• Legacy systems without a REST API: integration with ERPs and accounting systems that expose only native connectors or flat file exchange, made possible via scheduled scripts in the server cron

For Active Directory and SSO integration scenarios, see the detailed guide at Active Directory, LDAP e SSO com Bitrix24 self-hosted.

---

How the Development Workflow Works in Practice

The self-hosted customization workflow follows 7 mandatory stages - from briefing to post-deployment support - with the modified-file audit being the critical step that catalogs every change, classifies risks, and produces recommendations before any Bitrix24 version update.

The typical customization workflow in a self-hosted environment, from requirements gathering through production delivery:

The process begins with a client briefing, moves through technical analysis, development in a staging environment, a modification audit, and only then proceeds to production - with a mandatory prior backup.

flowchart TD
    A[Briefing & Requisito de Negócio] --> B[Análise Técnica: API REST resolve?]
    B -- Sim --> C[Desenvolvimento via REST/Webhook]
    B -- Não --> D[Customização em Self-Hosted]
    D --> E[Desenvolvimento em Homologação]
    E --> F[Auditoria de Arquivos Modificados]
    F --> G{Modificações documentadas?}
    G -- Não --> H[Documentar & Classificar Riscos]
    H --> F
    G -- Sim --> I[Backup do Portal]
    I --> J[Deploy em Produção]
    J --> K[Suporte Pós-Deploy]

The modification audit step is critical: it catalogs every altered file, classifies the risk level of each change, and generates recommendations - particularly important ahead of any Bitrix24 version update.

---

Real Limits: What You Cannot (or Should Not) Do

In self-hosted deployments, 4 risks account for the majority of production issues: editing the core without documentation (overwritten during updates), components without descriptions (requiring reverse engineering), outdated modules (vulnerability vectors), and server misconfigurations that amplify any customization failure.

Source code access is not unlimited. There are practical and technical constraints that every product owner should understand:

• Modifying the core without documentation is guaranteed technical debt. Version updates can overwrite altered files. Best practice is always to create proprietary components or modules rather than editing native ones.
• Poorly described custom components create diagnostic problems - in real projects we have encountered components with no description that required reverse engineering to understand their function.
• Outdated modules are vulnerability vectors. Self-hosted places the responsibility for keeping the core and modules up to date squarely on your team. Installations that go without updates accumulate documented security risks.
• Server misconfigurations (undersized database parameters, error logs exposed to end users) amplify any customization issue. The server must be hardened before any development work begins.

For a complete list of security checks, see the checklist de 25 pontos para Bitrix24 self-hosted.

---

Migrating from Cloud to Self-Hosted: The Starting Point for Customization

Migrating from Bitrix24 cloud to self-hosted follows 5 sequential stages - server scoping, license deployment, SSL and backup configuration, data migration, and 30 days of post-migration support - and is the mandatory starting point for anyone who needs customizations beyond what the cloud allows.

Many organizations arrive at self-hosted after discovering that the cloud version cannot accommodate the customizations they need. The migration process involves:

1. Technical server scoping (CPU cores, RAM, storage, DNS, SSL)
2. Deploying the self-hosted license, removing test data, and registering the license key
3. Configuring Push & Pull, an SSL certificate (Let's Encrypt or corporate), and automated backups
4. Migrating portal data and settings from the cloud
5. A post-migration support period (typically 30 days of warranty coverage on migrated items)

The complete guide is available at como migrar do Bitrix24 Cloud para o Self-Hosted.

---

Self-Hosted vs. Cloud: Decision Matrix for Customization

The decision matrix shows that 4 critical requirements - modifying the Gantt, integrating a legacy ERP without an API, replacing the map widget, and creating proprietary components - are impossible in the cloud and fully achievable in self-hosted, at the cost of taking on responsibility for server security.

Requirement	Cloud	Self-Hosted
Extra fields on CRM cards	✅ Native	✅ Native + code
Custom Smart Processes	✅ Native	✅ Native + handlers
Modifying the Gantt layout	❌ Not possible	✅ PHP/JS template
Legacy ERP integration without an API	❌ Limited	✅ Cron + direct PHP
Alternative map widget	❌ Not possible	✅ JS bundle replacement
Proprietary component	❌ Not possible	✅ Custom namespace
Control over version updates	❌ Automatic	✅ Managed by your team
Server security responsibility	❌ Bitrix	✅ Your team / partner

For a full 3-year total cost of ownership analysis comparing both options, see Self-Hosted vs Cloud Bitrix24: Análise TCO Completa.

---

When Self-Hosted Development Investment Is Justified

Development on the self-hosted source code is justified when at least one of 4 criteria is met: the required feature is absent from the Marketplace and not viable via REST, the organization has an IT team capable of maintaining documentation and managing updates, there is a regulatory or strategic data sovereignty requirement, or the user volume justifies dedicated infrastructure.

Based on our implementation experience, investing in self-hosted source code development is justified when:

• The required functionality does not exist in the Marketplace and cannot be built via REST API within a reasonable timeline and budget
• The organization has an internal IT team or a dedicated partner capable of maintaining modification documentation and managing the update cycle
• There is a data sovereignty requirement that prevents the use of the cloud - whether regulatory, contractual, or strategic
• The volume of users and transactions justifies dedicated infrastructure (see guia de dimensionamento de hardware)

If even one of these criteria applies, a technical feasibility assessment is the right first step - and it prevents projects that consume budget without delivering measurable value.

---

Working with a self-hosted partner. Want the control of Bitrix24 self-hosted without managing the server yourself? The 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.