Turnkey Server Environment Setup for 1C-Bitrix

Server Environment Setup for 1C-Bitrix

After a PHP update, your site often breaks. A typical scenario for 1C-Bitrix project owners: updating a module, switching PHP versions, or migrating to a new server often brings environment compatibility errors. The server environment setup is the key factor for stable operation. Incorrect php.ini parameters, missing extensions, wrong permissions lead to a white screen, 500 responses, or performance degradation. Our experience shows: a proper environment yields a 2–3x performance boost without changes in business logic.

White screen after PHP update is typical. Or the error mysql_* functions are deprecated when installing a new module. In 9 out of 10 cases, the problem is not in the code but in the environment: wrong versions, missing extensions, incorrect permissions. Proper setup not only eliminates errors but also significantly speeds up your site.

We are a team of certified 1C-Bitrix specialists. We'll set up your server environment turnkey so you can forget about compatibility. We've already configured over 50 projects — from simple VPS to high-load clusters.

What server requirements does 1C-Bitrix have?

Current recommendations for Bitrix (check the system requirements for your version):

Bitrix VM or manual setup?

Bitrix VM is the official installer for CentOS/Rocky Linux with ready-made configs and the bx-manage.sh script. It's good for a quick start but tied to a specific OS and hard to customize. Manual setup on Ubuntu/Debian gives full control: you choose component versions, easily integrate Docker, Ansible, GitLab CI. For projects with non-standard requirements, manual setup is 2–3 times more effective because it allows adapting every detail to business logic.

Why is proper PHP configuration critical?

Without precise tuning of PHP extensions and php.ini, Bitrix works unstably. Here are the mandatory extensions:

• mbstring — Cyrillic support
• gd or imagick — image resizing via CFile::ResizeImage()
• curl — HTTP requests (payments, integrations, SMS)
• soap — 1C integration
• zip — marketplace updates
• opcache — critical for performance
• pcre — component template engine

php.ini parameters for Bitrix:

memory_limit = 256M           ; minimum 128M, for 1C import — 512M
max_execution_time = 120      ; standard; for cron tasks — 0
upload_max_filesize = 100M    ; file uploads to media library
post_max_size = 110M
max_input_vars = 10000        ; Bitrix forms with many fields
default_charset = UTF-8
date.timezone = Europe/Moscow
opcache.enable = 1
opcache.memory_consumption = 256
opcache.max_accelerated_files = 20000
opcache.revalidate_freq = 60  ; in production can be 300

How to configure permissions and open_basedir?

Bitrix requires write access to several directories. Correct permissions are the foundation of security and stability:

chown -R www-data:www-data /var/www/bitrix
chmod -R 755 /var/www/bitrix
chmod -R 777 /var/www/bitrix/bitrix/cache
chmod -R 777 /var/www/bitrix/upload
chmod -R 777 /var/www/bitrix/bitrix/managed_cache

open_basedir is a frequent source of errors. If enabled, add Bitrix paths:

open_basedir = /var/www/bitrix:/tmp:/var/log/php

How to configure MySQL for Bitrix?

MySQL requires attention to innodb_buffer_pool_size (70% of RAM for InnoDB) and sql_mode. In MySQL 8.0, the default ONLY_FULL_GROUP_BY can break old queries. We usually set sql_mode = '' until refactoring. Also important: max_allowed_packet — set 256M for 1C integrations.

From our practice: migration to a new server

A client — an e-store with 10,000 products — migrated from shared hosting (PHP 7.4, MySQL 5.7) to VPS (PHP 8.1, MySQL 8.0). After migration, the catalog wasn't displayed, logs showed Notice: Undefined variable and mysql_num_rows(): Argument #1 must be of type mysqli_result. Cause: outdated template code used old MySQL API incompatible with PHP 8. We enabled error_reporting = E_ALL in dev environment, fixed outdated calls, replaced with $result->num_rows. Also temporarily set sql_mode = '' in MySQL 8 until refactoring. After setting up caching via Redis, page generation time halved. Server resource savings were around 30%. Additionally, agent execution time decreased by 50%, eliminating the need for an extra server.

What's included in server environment setup for 1C-Bitrix

• Analysis of the current stack — check versions, configurations, compatibility.
• Installation and configuration of the stack — PHP, MySQL, Nginx, Redis, Memcached.
• Optimisation of php.ini and my.cnf — tailored to your project's load.
• Permission setup — chmod, chown, open_basedir.
• Performance testing — load testing, caching verification.
• Documentation and training — we hand over access, configs, and maintenance instructions.

How we set up: stages of work

1. Analysis of the current environment and project requirements.
2. Design of the target stack considering load and budget.
3. Implementation: installation and configuration of all components.
4. Testing: functional, load, integration checks.
5. Launch and support: handover of documentation, post-launch assistance.

Estimated timeframes

• Standard project (VPS, no migration) — 1–2 days.
• Complex project (migration, non-standard stack) — 2–3 days.
• Full post-launch support — from 1 day per month.

Order a turnkey server environment setup for 1C-Bitrix. We'll assess your project within 1 day. Contact us — we'll select the optimal stack for your load.

Official 1C-Bitrix documentation

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.