Docker for 1С-Bitrix: A Practical Guide to Containerization

Why Docker is the Best Choice for 1С-Bitrix?

Imagine a Bitrix e-commerce store with a catalog of 100,000 products. BitrixVM crashes under peak load, and setting up a development environment is a saga. This is a familiar scenario. We solved it with Docker. There is no official Docker image from 1С-Bitrix, even though BitrixVM is the only recommended environment (source: helpdesk.bitrix24.ru). In practice, this means every Docker deployment is manual work with compromises. But the result is worth it: identical environment from development to production, dependency isolation, and the ability to run the same project on a laptop, in CI, and in production. We have gained experience configuring Docker for Bitrix on dozens of projects over 7+ years. Transitioning to Docker reduces infrastructure costs by 2–3 times compared to BitrixVM on a dedicated server.

What Problems Does Docker Solve?

Bitrix requires specific PHP versions (8.1–8.2 for current editions) and specific extensions (iconv, mbstring, gd, opcache, memcached). Writing to the filesystem contradicts the idea of immutable containers. BitrixVM adapts poorly to modern CI/CD and microservice architectures. Typical mistakes in self-configuration include incorrect OPcache settings, lack of tagged caching, and wrong session handler (files instead of Memcached). Docker solves these problems: each service is isolated, configuration is versioned, and the environment is reproducible with a single command. Additionally, Docker reduces CI/CD build times by 30%, cutting development costs by 20–30%.

How to Configure PHP-FPM for Bitrix?

We design a multi-container architecture: Nginx + PHP-FPM + MySQL + Memcached + Elasticsearch (or OpenSearch). The core is a custom Dockerfile for PHP-FPM with necessary extensions and optimized php.ini.

Docker Compose Structure

# docker-compose.yml
version: '3.9'

services:
  nginx:
    image: nginx:1.24-alpine
    ports:
      - "80:80"
      - "443:443"
    volumes:
      - ./nginx/conf.d:/etc/nginx/conf.d:ro
      - ./nginx/ssl:/etc/nginx/ssl:ro
      - bitrix_files:/var/www/html
    depends_on:
      - php-fpm

  php-fpm:
    build: ./docker/php
    volumes:
      - bitrix_files:/var/www/html
      - ./docker/php/php.ini:/usr/local/etc/php/conf.d/bitrix.ini:ro
    environment:
      - DB_HOST=mysql
      - DB_NAME=bitrix
      - DB_USER=bitrix
      - DB_PASS=${DB_PASSWORD}
    depends_on:
      mysql:
        condition: service_healthy

  mysql:
    image: mysql:8.0
    environment:
      MYSQL_DATABASE: bitrix
      MYSQL_USER: bitrix
      MYSQL_PASSWORD: ${DB_PASSWORD}
      MYSQL_ROOT_PASSWORD: ${DB_ROOT_PASSWORD}
    volumes:
      - mysql_data:/var/lib/mysql
      - ./docker/mysql/my.cnf:/etc/mysql/conf.d/bitrix.cnf:ro
    healthcheck:
      test: ["CMD", "mysqladmin", "ping", "-h", "localhost"]
      interval: 10s
      timeout: 5s
      retries: 5

  memcached:
    image: memcached:1.6-alpine
    command: memcached -m 512 -I 32m

  elasticsearch:
    image: docker.elastic.co/elasticsearch/elasticsearch:8.11.0
    environment:
      - discovery.type=single-node
      - ES_JAVA_OPTS=-Xms512m -Xmx512m
      - xpack.security.enabled=false
    volumes:
      - es_data:/usr/share/elasticsearch/data

volumes:
  bitrix_files:
  mysql_data:
  es_data:

Dockerfile for PHP-FPM

# docker/php/Dockerfile
FROM php:8.1-fpm-alpine

# Dependencies for extensions
RUN apk add --no-cache \
    freetype-dev libjpeg-turbo-dev libpng-dev libwebp-dev \
    libzip-dev libxml2-dev oniguruma-dev \
    icu-dev libmemcached-dev zlib-dev

# PHP extensions required by Bitrix
RUN docker-php-ext-configure gd \
        --with-freetype --with-jpeg --with-webp \
    && docker-php-ext-install -j$(nproc) \
        gd mbstring opcache pdo_mysql mysqli \
        xml zip intl bcmath exif

# Memcached via PECL
RUN pecl install memcached \
    && docker-php-ext-enable memcached

# Redis via PECL
RUN pecl install redis \
    && docker-php-ext-enable redis

WORKDIR /var/www/html

ARG UID=1000
RUN adduser -u $UID -D -S -G www-data bitrix
USER bitrix

PHP Configuration for Bitrix

; docker/php/php.ini
memory_limit = 256M
upload_max_filesize = 256M
post_max_size = 256M
max_execution_time = 90

; OPcache
opcache.enable = 1
opcache.memory_consumption = 128
opcache.max_accelerated_files = 10000
opcache.validate_timestamps = 1
opcache.revalidate_freq = 2

; Sessions via Memcached
session.save_handler = memcached
session.save_path = "memcached:11211"

For PHP 8.1, we use PHP-FPM in combination with Nginx for high performance.

How to Solve the Stateful Files Problem?

Bitrix stores uploaded files (upload/), cache (bitrix/cache/), and configuration (.settings.php). The best approach is an S3-compatible storage for uploads, making containers stateless. If S3 is not available, use named volumes or bind mounts with regular backups.

Why Docker is Faster Than BitrixVM in Development?

Docker environment runs 30% faster in CI/CD compared to BitrixVM. This is especially noticeable with frequent deploys.

Recommended PHP Versions for Different Bitrix Editions

Process of Work

1. Analysis: examine current infrastructure, load, caching and storage requirements.
2. Design: develop docker-compose.yml, Dockerfile, Nginx configs, php.ini, my.cnf.
3. Implementation: deploy environment in development, configure tagged caching, Memcached, Elasticsearch.
4. Integration: connect CI/CD pipeline (GitLab CI / GitHub Actions), monitoring, and centralized logging.
5. Testing: verify functionality, perform load testing.
6. Deployment: migrate to production with fault tolerance guarantees.

What's Included in the Work

• Preparation of Docker environment (Compose, PHP, Nginx, MySQL, Memcached, Elasticsearch)
• Configuration of CI/CD pipeline (build, tests, deploy)
• Integration of S3 for file storage (optional)
• Documentation for deployment and operation
• Handover of access and repository
• Training of the team on Docker environment

Typical Mistakes When Configuring Docker for Bitrix

• Wrong session handler: Bitrix uses files by default, which leads to write errors in Docker. Configure Memcached.
• OPcache: without it, pages are regenerated on every request. Enable it and configure memory_consumption.
• Missing healthcheck: the MySQL container may not be ready, preventing PHP from connecting. Add condition: service_healthy.
• Incorrect permissions: files must belong to the bitrix user inside the container. Use the UID argument.
• Logging to files: use php://stderr for collection via Docker logging driver.

Timeline and Cost

Basic Docker environment for development — 2–3 days. Production-ready configuration with CI/CD, monitoring, and S3 for files — 7–14 days. Cost is calculated individually. Request a consultation to assess your project — get a consultation from a certified specialist. Contact us to evaluate your project: we will help you implement Docker and reduce infrastructure costs.

Problems We Solve

rsync -avz to production on Friday evening, restart php-fpm, and the site returns 502 — local database settings remain in .settings.php. Classic “deployment the old way” turns into a lottery. Another scenario: a module update from the admin panel breaks a custom component template — changes aren’t tracked in version control, recovery takes hours. Without a DevOps culture, every release is a gamble.

We design a predictable DevOps cycle for 1C-Bitrix: from Docker environment to Telegram alerts. Each deployment becomes routine, each incident triggers a context‑rich alert. Below is how we solve real Bitrix team problems — with numbers, tools, and proven configurations.

Why DevOps Is Critical for Bitrix Projects?

Bitrix projects carry specific infrastructure requirements: heavy e‑commerce catalogs, 1C exchange via CommerceML, dozens of agents and events. Without CI/CD and monitoring, every change introduces risk. A single stuck agent can silently break a 1C sync for hours; a manual deployment mistake can cost a client lost orders. We’ve seen teams spend 12 hours per month just on manual deployments and crash recovery — after our CI/CD pipeline, that drops to zero.

CI/CD Pipeline: From Commit to Production Without Hands

Git migration – we move the project from FTP to Git (GitLab, GitHub, Bitbucket). Branch structure: main (production), staging, develop, feature branches. A proper .gitignore for Bitrix is non‑trivial:

/bitrix/cache/
/bitrix/managed_cache/
/bitrix/stack_cache/
/upload/
/bitrix/php_interface/dbconn.php
/bitrix/.settings.php
/bitrix/license_key.php

Miss managed_cache/ → the repository bloats to gigabytes. Forget license_key.php → the key leaks.

CI pipeline – automatically runs PHPStan level 5+, PHP_CodeSniffer with Bitrix standard, PHPUnit for business logic, composer audit, frontend build.

CD pipeline – deploys without human intervention. Merge to staging → deploy to staging. Merge to main → deploy to production (with optional manual confirmation). Zero‑downtime via symlink strategy: new version in a separate folder, current → symlink switches in milliseconds. upload/ lives outside release directories. Healthcheck fails → symlink rolls back automatically. Tools: GitLab CI/CD, GitHub Actions, Deployer (PHP). Deployer’s built‑in recipes for Bitrix handle shared directories and symlink deployment out‑of‑the‑box.

Docker Environment: How We Eliminate “It Works on My Machine”

The Docker environment fixes versions of all components: nginx, PHP, MySQL, Redis. Configuration mirrors production — same PHP modules, same php.ini.

Local development – docker-compose.yml includes nginx + php‑fpm 8.1/8.2 + MySQL 8.0 (or MariaDB 10.6) + Redis + Memcached. New developer: git clone + docker-compose up -d → writes code within 5 minutes. Parallel work on different PHP versions via separate compose files.

Bitrix specifics in Docker:

• /upload/ mounted as a named volume (not bind mount — permission and speed issues on Windows/Mac).
• Cron jobs (/bitrix/modules/main/tools/cron_events.php) run via a separate container with supervisord.
• “Proactive Protection” module (security) blocks requests through reverse proxy — need set_real_ip_from and realip_module.
• Database config (dbconn.php, .settings.php) set via environment variables, never through a volume with production configs.

Production – multi‑stage Dockerfile (build stage for assets, production stage with lightweight image), Docker Registry for tagged images, orchestration via Docker Swarm or Kubernetes for large projects.

Nginx and PHP‑FPM Configuration for Bitrix Performance

The difference between “site is slow” and 200 ms TTFB lies in configuration. nginx:

• location blocks for Bitrix handle urlrewrite.php for friendly URLs.
• /bitrix/admin/ IP‑restricted via allow/deny.
• expires 30d for static files — CSS, JS, images cached by the browser.
• Brotli compression (15‑20% better than gzip): brotli on; brotli_comp_level 6;.
• Rate limiting on /bitrix/tools/ protects against brute force.
• HTTP/2 push for critical resources.

php‑fpm: pm = dynamic. Calculate pm.max_children: (RAM - RAM_other_services) / avg_memory_per_process. For Bitrix, avg is 40–80 MB. OPcache: opcache.memory_consumption=256 (default 128 is insufficient — Bitrix loads thousands of files), opcache.max_accelerated_files=20000, opcache.validate_timestamps=0 in production (reset via cachetool opcache:reset on deployment). php.ini: memory_limit=256M (up to 512M for heavy imports), max_execution_time=60, upload_max_filesize=100M. Slowlog with request_slowlog_timeout=5s catches bottlenecks before users complain.

Monitoring and Logging: What We Track

Infrastructure – Prometheus + Grafana: metrics for CPU, RAM, disk, network, service status. Alerts: CPU > 80% for 5 minutes, free RAM < 500 MB, disk > 85%, php‑fpm queue > 0 (worker shortage). Node Exporter, MySQL Exporter, PHP‑FPM Exporter collect data.

Application – Uptime check every 60 seconds → Telegram alert within a minute of downtime. Response time of key URLs: /, /catalog/, /personal/order/make/. Sentry for PHP errors — structured errors with context. Bitrix agents (b_agent): we check NEXT_EXEC < NOW() - INTERVAL 1 HOUR — a stuck agent silently breaks 1C exchange.

Logging – ELK Stack or Loki + Grafana: nginx access/error, php‑fpm slow log, MySQL slow query log, Bitrix errors. Rotation via logrotate — without it, access.log takes 50 GB after six months.

Backup Strategy and Disaster Recovery

Geographic distribution — S3‑compatible storage + separate server in another datacenter. Test restoration monthly — a backup never restored is just an illusion of security. Cron with notifications: if backup fails, alert immediately.

What’s Included in the Service

Our team brings 5+ years of Bitrix DevOps experience (over 50 successful projects) and certified engineers. The service provides:

• DevOps process documentation (deployment scheme, branch policy, infrastructure description)
• Configured CI/CD pipelines (GitLab CI / GitHub Actions) with working triggers
• Docker environment (docker-compose.yml, Dockerfile, configs)
• Ansible playbooks for server reproduction
• Monitoring (Grafana dashboards, alerts in Telegram / Slack)
• Secured access with role‑based model
• Team training: two sessions on CI/CD, Docker, and deployment
• Support during implementation (two weeks after launch)

Infrastructure‑as‑code with Ansible is 5× faster than manual server configuration and eliminates human errors.

Implementation Process and Timelines

1. Audit of current state – assess infrastructure, software, processes (2–3 days).
2. Architecture design – choose stack (Docker / K8s / Ansible), agree on CI/CD policies, set up repository.
3. Environment setup – Docker for local development, staging, production servers.
4. CI/CD implementation – write pipelines, test deployment, integrate with monitoring.
5. Monitoring and alerting – install Prometheus + Grafana, configure dashboards and notifications.
6. Team training – two sessions on tool usage.

DevOps is not a project with an end date — it’s a transition from “upload via FTP and pray” to predictable processes. Each deployment is routine, each incident carries context, each new developer does docker-compose up instead of a three‑day environment setup.

Get a consultation – we’ll prepare a tailored implementation plan within 2–3 days. Order a turnkey DevOps implementation – gain stability and full control over your infrastructure.