Boxed Bitrix24 in Docker: CI/CD, anonymized dumps, backups and monitoring
The portal was deployed and updated by hand, the daily backup claimed in the documentation did not actually exist on any server, and development ran on copies of production with personal data.
The boxed Bitrix24 core is updated by the vendor and changes the database schema itself — it cannot be rebuilt from git. Production cannot be stopped, and the insurer's client personal data must not leave production.
- Production from scratch in one command on Rocky Linux 9: packages, Docker, code, configs, database and a check — idempotent, with no secret regeneration
- Deployment via GitLab CI only after a green preprod and a production preflight check; after deployment — a smoke check and schema comparison with preprod
- An anonymized dump is the only data format for local and preprod environments: secrets, phones and personal data are masked before hand-off
- Backups of the database, files and configs with a mandatory restorability check into a temporary database
- Core update in one command: a restore point, "before" and "after" schema snapshots and a change manifest
- Schema migrations with a log and a lock against parallel runs; monitoring on Prometheus and Grafana with Telegram notifications
The portal is deployed and updated reproducibly: the schema is managed by 235 migrations, and changes are covered by 95 PHPUnit test files (over 700 tests) plus frontend tests. A backup counts as working only after a verified restore.
Related services and solutions
Bitrix24 D7: boxed development and stabilization
I work not only with interface settings, but at the level of the box, the code and internal APIs.
Business process automation
When employees transfer data manually, reconcile spreadsheets, lose requests or repeat the same actions — I turn the routine into code.