Что можно в коробке Битрикс24, чего нельзя в облаке: доработки без лимитов

Коробочный Битрикс24 открывает доступ к исходному коду, файловой системе и ядру платформы — это принципиально другой уровень кастомизации по сравнению с облаком. Если вы упёрлись в ограничения облачной песочницы, коробка снимает их на уровне архитектуры.

Облако против коробки: в чём принципиальная разница

В облачном Битрикс24 вы работаете внутри изолированной среды вендора: доступны только REST API, маркетплейс-приложения и стандартные настройки интерфейса. Никакого доступа к файловой системе, серверу, базе данных или коду ядра.

Коробка — это полноценная установка на вашем сервере. Вы получаете:

• полный доступ к файловой системе и директориям продукта;
• возможность запускать произвольный PHP-код в рамках платформы Bitrix Framework;
• прямое управление сервером, СУБД, конфигурацией PHP и веб-сервера;
• контроль над обновлениями, расписанием задач и инфраструктурой.

Это не просто «больше настроек» — это другой уровень ответственности и возможностей одновременно. Подробнее о том, почему растущие компании делают этот шаг, читайте в статье о причинах перехода на коробку.

Папка /local: безопасная зона для всех доработок

Главное правило разработки под Битрикс24: никогда не правьте ядро — файлы в /bitrix/. При каждом обновлении платформы они перезаписываются, и все изменения теряются.

Коробка предоставляет специально выделенную директорию /local/, которая при обновлениях не затрагивается. Именно здесь живут все кастомные доработки:

Поддиректория	Что размещается
/local/modules/	Собственные модули
/local/components/	Кастомные компоненты и их шаблоны
/local/templates/	Шаблоны дизайна портала
/local/php_interface/	Обработчики событий ядра, глобальные хуки
/local/activities/	Кастомные действия для бизнес-процессов

В облаке этой директории у вас нет физически — она есть только в коробке. Именно поэтому глубокие доработки в облаке невозможны в принципе: нет места, куда их безопасно положить.

На практике это означает, что разработчик коробочного портала работает в своей IDE, коммитит в git и деплоит в /local/ — стандартный процесс веб-разработки. Прежде чем формализовать доработку, полезно составить полноценное ТЗ: о структуре такого документа читайте в нашем руководстве.

Собственные модули, компоненты и шаблоны

Официальная справка Битрикс24 прямо указывает: владельцы коробки могут существенно дополнять и изменять функционал продукта под свои нужды — как самостоятельно, так и с помощью партнёров.

Что это даёт на практике:

• Свои модули — полноценные расширения платформы с собственными таблицами в БД, административными страницами, REST-методами и событиями. Модуль устанавливается через стандартный механизм и обновляется независимо от ядра.
• Кастомные компоненты — переопределение стандартных компонентов Битрикс24 или создание новых. Можно полностью переписать логику отображения карточки сделки, списка задач, страниц экстранета.
• Шаблоны дизайна — собственный шаблон портала: HTML, CSS, JS, графика. Портал может выглядеть совершенно не как стандартный Битрикс24 — корпоративный стиль, брендинг, нестандартная навигация. Менять шаблон отдельной страницы можно прямо из административного раздела.
• Готовое решение в Маркетплейс — если доработка имеет потенциал для тиражирования, её можно опубликовать в каталоге приложений для всех пользователей Битрикс24.

В облаке кастомные компоненты и модули недоступны — там работают только приложения из Маркетплейс24 и вебхуки.

Обработчики событий ядра

Это одна из самых мощных возможностей коробки, которой в облаке нет совсем.

Обработчики событий — механизм, позволяющий «подписаться» на любое системное событие и выполнить свой код в момент его возникновения. Примеры событий:

• создание или изменение лида, сделки, контакта в CRM;
• изменение статуса задачи;
• добавление или увольнение пользователя;
• отправка письма или входящее обращение в открытую линию;
• любое действие в бизнес-процессе.

В облаке вы можете реагировать на события только через REST-вебхуки — с задержкой, с ограничениями по частоте и только на те события, которые вендор решил вынести в API. В коробке обработчик события выполняется прямо внутри PHP-процесса, синхронно, без задержек и без каких-либо ограничений по частоте.

Это критично для сценариев вроде: автоматическое изменение нескольких связанных сущностей при одном действии менеджера, сложная валидация данных до сохранения, немедленная синхронизация с внешней системой.

О том, как работать с вебхуками смарт-процессов, читайте в нашем техническом гайде.

REST API и фоновые задачи без облачных лимитов

В облачном Битрикс24 REST API работает с жёсткими ограничениями на частоту запросов. При интеграции с 1С, ERP или любой внешней системой, которая генерирует большой поток операций, эти лимиты становятся узким местом.

Что меняется в коробке:

• REST API работает на вашем сервере — никаких внешних rate limit от вендора;
• тяжёлые фоновые операции (массовый импорт, перерасчёт данных, генерация отчётов) не упираются в облачные квоты;
• агенты и cron — в коробке можно регистрировать собственные агенты Bitrix Framework, которые выполняются по расписанию прямо на сервере, без внешних триггеров;
• объём диска, количество пользовательских полей и размер выгрузок ограничены только вашим железом, а не тарифным планом.

Для интеграций с 1С это особенно важно: при синхронизации каталога из нескольких тысяч позиций облачный лимит REST становится критичным. В коробке та же синхронизация работает без throttling. Подробнее об интеграции с 1С читайте в нашем разборе трёх рабочих сценариев.

Прямой доступ к базе данных и внутренней инфраструктуре

Коробка стоит на вашем сервере — а значит, у вас есть прямой доступ к СУБД MySQL/MariaDB.

Что это открывает:

• Произвольные SQL-запросы для отчётности — сложная аналитика, которую невозможно собрать стандартными отчётами Битрикс24, строится прямым запросом к БД (рекомендуется только чтение, без прямой записи в обход ORM).
• Интеграция на уровне сервера — синхронизация с внутренними системами компании (ERP, ИБ-инфраструктура, корпоративные базы данных) через прямые серверные соединения, без публичных API.
• AD/LDAP и SSO — централизованное управление доступом через интеграцию с Active Directory, «прозрачный» вход доменных пользователей через Kerberos или NTLM.
• Кастомная конфигурация PHP и веб-сервера — оптимизация под реальную нагрузку: настройка пулов PHP-FPM, буферов MySQL, опкэша, memcached или Redis.
• Локальная разработка в Docker — среда разработки через bitrixdock (GitHub: bitrixdock/bitrixdock) с выбором версии PHP (до PHP 8.2), типа веб-сервера и СУБД; всё версионируется в git и воспроизводимо на любом стенде.

На схеме показано, как коробочный Битрикс24 взаимодействует с внутренней инфраструктурой компании: внешние источники (сайты, телефония) передают события напрямую на сервер, который двусторонне синхронизируется с 1С и корпоративными системами, не выходя за пределы контура.

flowchart LR
    SITES[Сайты / формы] --> B24[Битрикс24\nна своём сервере]
    PHONE[Телефония / SIP] --> B24
    B24 <--> ONE_C[1С / ERP]
    B24 <--> LDAP[AD / LDAP]
    B24 --> DB[(MySQL / MariaDB)]
    B24 --> CRON[Агенты / cron]

Хранение данных в своём контуре

Для ряда отраслей и компаний размещение данных на серверах вендора — не вопрос удобства, а требование регулятора или внутренней политики безопасности.

Коробка позволяет держать все данные исключительно на собственной инфраструктуре: ни CRM-контакты, ни файлы, ни история переписки не покидают ваш контур. Это напрямую связано с требованиями 152-ФЗ о персональных данных — подробнее об этом аспекте читайте в отдельной статье Коробка Битрикс24 и 152-ФЗ.

Важный нюанс: ряд облачных сервисов Битрикс24 (BitrixGPT, КЭДО, Битрикс24.Docs, умные реквизиты, BI-конструктор, сквозная аналитика с рекламными кабинетами) работает только при подключении к облачным серверам вендора и в полностью закрытом контуре недоступен. Это нужно учитывать при проектировании архитектуры.

Правильный подход к доработкам: принцип «не трогать ядро»

Коробка даёт свободу, но эта свобода требует дисциплины. Аудит одного из реальных порталов показал: из 109 188 проверенных файлов были изменены 23 файла в ядре (модули crm, im, tasks, location, socialnetwork). Такие правки затрутся при обновлении платформы.

Золотое правило: все кастомные доработки — только через /local/, события и собственные модули. Никогда не редактируйте файлы в /bitrix/.

Конкретный порядок действий:

1. Переопределяйте компоненты через /local/components/ — копия шаблона из /bitrix/components/ с вашими изменениями.
2. Регистрируйте обработчики событий в /local/php_interface/init.php.
3. Создавайте собственные модули в /local/modules/ с полным циклом установки/удаления.
4. Совместную разработку ведите через git с ветками (gitflow), деплой — через CI/CD или вручную.

Дополнительная ответственность коробки — сервер, обновления и безопасность на вашей стороне. Устаревшее окружение (например, CentOS 7, PHP ниже 8.2) создаёт уязвимости и блокирует обновления продукта. Подробнее о том, почему это важно и как действовать, читайте в статье про обновление коробочного Битрикс24.