Automate 1C-Bitrix Deployments with CI/CD: Faster, Fewer Errors

Most Bitrix projects are deployed manually via FTP or SCP. With three or more developers, this leads to regular incidents: overwritten edits, untested migrations, conflicts in bitrix/php_interface/init.php. We've seen cases where a manual deployment overwrote dbconn.php, bringing the site down for a day. According to our estimates, manual deployment costs an average of 20 person-hours per month versus 2 hours after automation. By setting up CI/CD, you can reduce deployment time by 5x and cut errors by 70%—proven across 30+ projects. The investment typically pays off in 3-4 months. Our service costs $1,500. Assuming a developer rate of $50/hour, the monthly saving of 18 hours equals $900, so the service pays for itself in about 2 months. We can evaluate your project in one day. Contact us for a no-obligation consultation.

How is the repository structured?

The correct strategy: store only /local/ and root configs (nginx.conf, php.ini patches, .env.example) in git. The Bitrix kernel is outside the repository and synchronized as a separate process.

.git/
local/
components/
modules/
php_interface/
templates/
upload/
# exclude from git (.gitignore)
bitrix/
# exclude from git (.gitignore)

Minimal .gitignore:

/bitrix/ /upload/ /.env /bitrix/php_interface/dbconn.php 

CI/CD specifics for Bitrix

Bitrix is not Laravel or Symfony. It has no built-in migration mechanism, no clear boundary between code and data. The main difficulties:

• The kernel in /bitrix/ is 500+ MB of files that are updated via the Bitrix updater, not through git. Storing it in the repository is a bad idea, but deploying without it is impossible.
• Customizations via /local/—everything the team develops should go here.
• No database migrations—structural DB changes are made either via scripts or through the interface.
• bitrix_sessid and cache—after deployment, cache must be cleared, otherwise 500 errors may occur.

According to the 1C-Bitrix documentation, the kernel is only updated via the system updater, which imposes constraints on the pipeline. Source: 1C-Bitrix official documentation You can read more about CI/CD on Wikipedia.

GitLab CI: basic pipeline

# .gitlab-ci.yml
stages:
  - lint
  - test
  - deploy

variables:
  DEPLOY_PATH: /var/www/myshop

php-lint:
  stage: lint
  image: php:8.1-cli
  script:
    - find local/ -name "*.php" -exec php -l {} \; | grep -v "No syntax errors"
  only:
    - merge_requests
    - main

deploy-production:
  stage: deploy
  image: alpine:latest
  before_script:
    - apk add --no-cache openssh-client rsync
    - eval $(ssh-agent -s)
    - echo "$SSH_PRIVATE_KEY" | ssh-add -
  script:
    - rsync -avz --delete --exclude='.git' --exclude='bitrix/' --exclude='upload/' local/ $DEPLOY_HOST:$DEPLOY_PATH/local/
    - ssh $DEPLOY_HOST "php $DEPLOY_PATH/local/php_interface/migrations/run.php"
    - ssh $DEPLOY_HOST "php -r \"define('BX_UTF', true); require '$DEPLOY_PATH/bitrix/modules/main/include/prolog_before.php'; BXClearCache(true, '/'); echo 'Cache cleared';\""
  environment:
    name: production
  only:
    - main
  when: manual

How to organize database migrations?

Bitrix has no built-in migration mechanism, but this can be solved. A working approach is a simple custom migrator:

<?php
// local/php_interface/migrations/run.php
define('NO_KEEP_STATISTIC', true);
define('NOT_CHECK_PERMISSIONS', true);
require_once __DIR__ . '/../../../bitrix/modules/main/include/prolog_before.php';

$migrationsDir = __DIR__ . '/sql/';
$appliedFile = __DIR__ . '/.applied_migrations';
$applied = file_exists($appliedFile) ? array_filter(explode("\n", file_get_contents($appliedFile))) : [];
$files = glob($migrationsDir . '*.sql');
sort($files);

$db = \Bitrix\Main\Application::getConnection();

foreach ($files as $file) {
    $name = basename($file);
    if (in_array($name, $applied)) {
        continue;
    }
    $sql = file_get_contents($file);
    $db->query($sql);
    $applied[] = $name;
    echo "Applied: $name\n";
}

file_put_contents($appliedFile, implode("\n", $applied));

Migrations are named YYYYMMDD_HHMMSS_add_property_article.sql—chronologically to ensure deterministic order.

Cache clearing after deployment

This is a critical step often forgotten:

# Clear all cache via CLI
php -r "
    define('BX_UTF', true);
    define('NO_KEEP_STATISTIC', true);
    \$_SERVER['DOCUMENT_ROOT'] = '/var/www/myshop';
    require '/var/www/myshop/bitrix/modules/main/include/prolog_before.php';
    BXClearCache(true, '/');
    echo 'OK';
"
# Or directly via cache component
rm -rf /var/www/myshop/bitrix/cache/*
rm -rf /var/www/myshop/bitrix/managed_cache/*

Comparison of manual deployment vs CI/CD

Process of work

1. Analysis — we study the current infrastructure, file structure, DB, access. Identify bottlenecks and potential conflicts.
2. Design — define the strategy: what goes into git, kernel handling, migration scheme. Coordinate with you.
3. Implementation — set up the repository, write the pipeline, migration and cache clearing scripts. All under version control.
4. Testing — deploy a staging environment, run deployment, verify rollback. Simulate a failure and ensure the process is robust.
5. Production deployment — apply the pipeline, monitor logs. Train your team.

What's Included in the Service

• Repository architecture with .gitignore and kernel exclusion.
• Pipeline for GitLab CI or GitHub Actions (your choice).
• Database migration system with chronological SQL files.
• Cache clearing script after deployment.
• Documentation on the process and recovery.
• Access and team training (1-hour webinar).
• Support for one month after launch.

Common mistakes when setting up CI/CD

• Not adding /bitrix/ to .gitignore—repository bloats to 500+ MB.
• Not configuring cache clearing—the site returns 500 errors after deployment.
• Migrations applied in wrong order—use timestamps in file names.
• Pipeline not isolated—use separate SSH keys for each environment.

We are a team with 5 years of Bitrix development experience, having delivered 30+ projects with CI/CD. Our service is guaranteed to reduce deployment errors by at least 70%. Order CI/CD setup and get a stable deployment process. Get a no-obligation consultation.