Configuring Bitrix24 On-Premise Updates
Updating boxed Bitrix24 is not a "click Update and you're done" button. Without preparation, an update can break custom modifications, disrupt module functionality, or take several hours on a production server. The process needs to be structured as a procedure.
How the Update System Works
Bitrix24 On-Premise receives updates via "Marketplace" and built-in updater. The update system component is /bitrix/updates/. When run, it checks for available patches on the update server dev.1c-bitrix.ru, downloads packages, and applies changes to files and database.
Updates are of two types:
- Patch — point fix, affects individual files
-
Release — major update with database structure changes (
b_*tables)
Releases are riskier: they contain database migrations via \Bitrix\Main\Application::getConnection()->queryExecute(). If custom code uses non-standard fields in system tables, migration can corrupt data.
Configuring Auto Updates
In /bitrix/admin/update_system_partner.php you can enable automatic update retrieval and application on schedule. This is convenient, but risky for production without testing.
Sensible strategy: auto-updates are enabled only for security patches (SECURITY = Y). Major updates — only manually after staging testing.
Configuration via agent in b_agent:
// Agent checks for updates every 24 hours
CAgent::AddAgent(
"CUpdateClient::CheckUpdates();",
"main",
"N",
86400,
"",
"Y"
);
Production Update Procedure
Step 1: Backup. Before any update — backup files and database. Built-in backup module (/bitrix/admin/backup.php) or mysqldump + tar:
mysqldump -u bitrix -p bitrix24_db > /backup/bitrix24_$(date +%Y%m%d_%H%M).sql
tar czf /backup/bitrix24_files_$(date +%Y%m%d_%H%M).tar.gz /var/www/html --exclude=/var/www/html/upload
Step 2: Test on staging. If you have a staging server (and you should) — apply the update there, run functional testing. Check:
- Custom components in
/local/components/ - Custom handlers in
/local/php_interface/init.php - Modules in
/local/modules/ - Integrations with external systems (1C, CRM)
Step 3: Maintenance mode. Before production update — maintenance mode. In Bitrix this is done via /bitrix/.maintenance.php:
<?php
// /bitrix/.maintenance.php
header('HTTP/1.1 503 Service Unavailable');
header('Retry-After: 3600');
include '/path/to/maintenance_page.html';
exit;
And in nginx intercept all requests and show the maintenance page.
Step 4: Apply update. Via /bitrix/admin/update_system.php or via console update handler (BitrixVM has bitrix-env).
Step 5: Post-update verification. List of critical pages: home, catalog, product card, cart, checkout, personal account, admin panel. Check php-fpm and nginx logs for new errors.
Updating Custom Modules from Marketplace
Marketplace modules update separately from the core. In /bitrix/admin/partner_modules.php is the list of installed modules with available updates. Before updating a third-party module — read the changelog: some modules reset settings on update.
Custom modules in /local/modules/ are outside the Marketplace update zone — update manually or via your CI/CD.
Version Control for Custom Code
The main problem when updating: developers often modify Bitrix core files (/bitrix/modules/) instead of using /local/. When the core updates, such changes get overwritten.
Check before updating: are there modified files in /bitrix/ (not in /local/). With Git this is simple: if /bitrix/ is under version control, git diff shows changes. If not — compare file hashes with the reference distribution.
Best practice: all custom code — only in /local/. Then core update is safe.