Docker Container Setup for 1C-Bitrix: From Chaos to Stability
We often see Bitrix Dockerized with a simple docker-compose up. But stable production operation—with correct restart policies, permissions, log rotation, and seamless updates—is our specialty. Statistics: 90% of help requests involve Bitrix writing files as one user while nginx reads them as another; OPcache not seeing code changes; agents not running due to missing cron inside the container. Let's solve these with practical examples that save up to 40% maintenance time.
Problems Solved by Proper Docker Setup for Bitrix
Without proper configuration, Bitrix containers in production become a headache. Here's what we encounter most:
- File permissions: files created by different users, causing 403 or 500 errors. Case: a client lost 2 days finding the cause until we set UID via build-arg. UID mapping is 10 times more reliable than manual chmod after every deploy.
- Downtime during updates: without a rolling update strategy, each release means minutes of unavailability. For an e-commerce store with significant turnover, that's a substantial loss for even a few minutes of downtime.
- Disk overflow: container logs without rotation grow to 5 GB in a week. While SSD cost is manageable, the risk of failure due to full disk is real.
Setting Up File Permissions in Docker for Bitrix
Classic issue: PHP-FPM inside the container runs as www-data (UID 33), while files on the volume are owned by root or another host user. Bitrix cannot write cache or save uploaded files.
We solve this by explicitly setting UID in Dockerfile:
FROM php:8.1-fpm-alpine ARG HOST_UID=1000 RUN addgroup -g $HOST_UID bitrix && adduser -u $HOST_UID -G bitrix -D bitrix RUN sed -i 's/user = www-data/user = bitrix/g' /usr/local/etc/php-fpm.d/www.conf \ && sed -i 's/group = www-data/group = bitrix/g' /usr/local/etc/php-fpm.d/www.conf In docker-compose.yml pass the argument:
php-fpm: build: context: ./docker/php args: HOST_UID: ${HOST_UID:-1000} Official 1С-Bitrix documentation recommends UID mapping for Docker containers.
Compare: with default www-data you get 403 errors everywhere; with UID mapping—full compatibility with host permissions. For security, we also block access to Bitrix service directories via nginx.
Configuring nginx for Production
server { listen 80; server_name _; root /var/www/html; index index.php; charset utf-8; client_max_body_size 256m; location ~* /\.ht { deny all; } location ~* /bitrix/modules { deny all; } location ~* /bitrix/php_interface { deny all; } location ~* /bitrix/tools { deny all; } location ~* \.(jpg|jpeg|png|gif|webp|svg|ico|css|js|woff2)$ { expires 30d; add_header Cache-Control "public, no-transform"; try_files $uri =404; } location / { try_files $uri $uri/ /bitrix/urlrewrite.php$is_args$args; } location ~ \.php$ { fastcgi_pass php-fpm:9000; fastcgi_index index.php; fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name; include fastcgi_params; fastcgi_read_timeout 300; fastcgi_send_timeout 300; } location = /bitrix/urlrewrite.php { fastcgi_pass php-fpm:9000; fastcgi_param SCRIPT_FILENAME $document_root$$fastcgi_script_name; include fastcgi_params; } } Healthcheck and Restart Policies
Add a healthcheck to verify container state:
healthcheck: test: ["CMD-SHELL", "php-fpm -t && kill -0 1"] interval: 30s timeout: 10s retries: 3 start_period: 40s This checks configuration validity and process liveness. As noted in Docker, healthcheck is mandatory for production.
Choose restart policy:
| Policy | Behavior | Recommendation |
|---|---|---|
restart: always |
Always restarts—after crash, Docker restart, even after docker stop. |
For MySQL: ensures DB starts whenever daemon boots. |
restart: unless-stopped |
Restarts after crash and Docker restart, but not after docker stop. |
For nginx and php-fpm: gives control—if stopped manually, there was a reason. |
Comparison of Common Problems and Solutions
| Problem | Solution | Effectiveness |
|---|---|---|
| File permissions | UID mapping in Dockerfile | 100% elimination of 403 errors |
| Disk overflow | Log rotation (max-size, max-file) | Up to 80% disk space savings |
| Downtime during updates | Rolling update via --no-deps | Zero-downtime update, 0 seconds downtime |
Why Log Rotation Matters
Without rotation, logs can eat tens of gigabytes in a week. Configure in docker-compose.yml:
services: nginx: logging: driver: "json-file" options: max-size: "50m" max-file: "5" php-fpm: logging: driver: "json-file" options: max-size: "100m" max-file: "3" Or globally via /etc/docker/daemon.json. Disk space savings up to 80%.
How to Update Bitrix Containers Without Downtime
Use a strategy updating only php-fpm, leaving nginx untouched:
-
docker-compose pull php-fpm -
docker-compose up -d --no-deps --build php-fpm
This takes seconds—nginx continues accepting requests and routes them to the old container while the new one starts. For large projects with replicas, update them one by one. Advanced config can achieve 100% uptime during updates.
What's Included in Turnkey Setup
- Configuration of nginx, PHP-FPM, MySQL with platform-specific tuning.
- File permission solution via UID mapping.
- Healthcheck and restart policies for all services.
- Log rotation and backup (database + files).
- Deployment and maintenance documentation.
- 30 days of free support after launch.
Backup Strategy
For reliability, we use a script that dumps the database and archives files. The script runs via host cron and stores backups for the last 7 days.
We will evaluate your project in one business day—no upfront payment. Contact us to discuss details. Order the setup—and forget about container problems.

