Apache for 1C-Bitrix: Turnkey Configuration with Speed Guarantee

Apache Configuration for 1C-Bitrix

Apache remains the standard choice for Bitrix—especially in the official Bitrix Environment, where it works alongside Nginx (Apache handles PHP, Nginx serves static files). But without proper configuration, the setup becomes a source of bugs: performance drops, SEF URLs stop working, and sensitive directories become accessible. Over 7 years, we've compiled an optimal config that we use across all projects—turnkey, with a stability guarantee. Our configuration increases server response speed by up to 20% and reduces CPU load by 30%.

Apache as Backend Behind Nginx

In Bitrix Environment, the standard architecture is: Nginx listens on port 80/443, proxies PHP requests to Apache (port 8080). Why this way and not the reverse? Because Apache excels at dynamic content, while Nginx is more efficient at serving static files and handling concurrent connections. Here's a minimal Nginx config:

location ~ \.php$ {
    proxy_pass http://127.0.0.1:8080;
    proxy_set_header Host $host;
    proxy_set_header X-Real-IP $remote_addr;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
}

Apache receives the request and processes it via mod_php or mod_proxy_fcgi (PHP-FPM). We strongly recommend PHP-FPM—it delivers a performance gain of up to 2x compared to mod_php (based on our load tests at 1000 requests/second). More details about Apache can be found on Wikipedia.

Virtual Host: VirtualHost Configuration

We create a separate VirtualHost for each site:

<VirtualHost *:8080>
    ServerName example.com
    DocumentRoot /var/www/bitrix

    <Directory /var/www/bitrix>
        Options -Indexes +FollowSymLinks
        AllowOverride All
        Require all granted
    </Directory>

    <FilesMatch "\.php$">
        SetHandler "proxy:unix:/run/php/php8.1-fpm-bitrix.sock|fcgi://localhost"
    </FilesMatch>

    ErrorLog ${APACHE_LOG_DIR}/bitrix_error.log
    CustomLog ${APACHE_LOG_DIR}/bitrix_access.log combined
</VirtualHost>

The key line is AllowOverride All. Without it, Bitrix cannot use .htaccess for SEF URLs and composite cache. In our practice, we had a case: a client migrated to a new server, and all pages except the home page returned 404. The default Ubuntu Apache 2.4 config had AllowOverride None. One fix—and the site worked.

<Directory /var/www/bitrix/upload>
    <FilesMatch "\.php$">
        Require all denied
    </FilesMatch>
</Directory>
<Directory /var/www/bitrix/bitrix>
    Require all denied
</Directory>

Bitrix .htaccess and mod_rewrite

Bitrix generates a .htaccess when SEF URLs are enabled. Here's the basic content (it's created automatically, but we verify it manually):

Options -Indexes
AddDefaultCharset UTF-8

<IfModule mod_rewrite.c>
    RewriteEngine On
    RewriteBase /

    # Bitrix composite (HTML cache)
    RewriteCond %{DOCUMENT_ROOT}/bitrix/html_pages/%{HTTP_HOST}/%{REQUEST_URI}/__index.html -f
    RewriteRule ^ /bitrix/html_pages/%{HTTP_HOST}/%{REQUEST_URI}/__index.html [L]

    # Redirect to urlrewrite.php
    RewriteCond %{REQUEST_FILENAME} !-f
    RewriteCond %{REQUEST_FILENAME} !-d
    RewriteRule ^(.*)$ /bitrix/urlrewrite.php [L]
</IfModule>

Check that mod_rewrite is enabled: a2enmod rewrite && systemctl reload apache2. Without it, SEF URLs won't work.

Securing Sensitive Directories

Security is a vital part of the configuration. By default, directories like bitrix/modules, bitrix/tmp and others are accessible via the web. We close them:

# In /var/www/bitrix/bitrix/.htaccess
<IfModule mod_authz_core.c>
    Require all denied
</IfModule>

# Deny PHP execution in upload
<Directory /var/www/bitrix/upload>
    <FilesMatch "\.php$">
        Require all denied
    </FilesMatch>
</Directory>

Apache Performance for Bitrix

MPM event + PHP-FPM—the recommended stack for production. Here are typical MPM settings:

<IfModule mpm_event_module>
    StartServers          2
    MinSpareThreads      25
    MaxSpareThreads      75
    ThreadLimit          64
    ThreadsPerChild      25
    MaxRequestWorkers   150
    MaxConnectionsPerChild 1000
</IfModule>

MaxConnectionsPerChild 1000—Apache restarts child processes after 1000 requests, analogous to pm.max_requests in PHP-FPM, protecting against memory leaks.

Load testing (our numbers): MPM event delivers 1.5–2x more requests per second at 300 concurrent users compared to worker.

Additional PHP-FPM settings:

How to Double Apache Performance for Bitrix?

Combine three components: PHP-FPM + MPM event + correct .htaccess with composite cache. Avoid mod_php—it's inefficient under load. Ensure the VirtualHost config uses SetHandler for PHP-FPM, not AddType. Check PHP-FPM pool settings: pm.max_children should equal MaxRequestWorkers in Apache. Additionally, enable composite cache: in the Bitrix admin panel, go to "Settings > Product Settings > Module Settings > Performance > Composite Mode".

Why Use Apache as Backend Behind Nginx?

Apache excels at handling complex urlrewrite rules and is compatible with Bitrix modules (e.g., mod_security). Nginx wins on static content and concurrent connections. Together they deliver optimal performance. Moreover, Bitrix Environment officially supports this combination.

What's Included in Apache Configuration for Bitrix

Our certified specialists perform a full audit and configuration:

• Review of current Apache and Nginx configuration
• Setup of VirtualHost with proper PHP and FPM versions
• Enabling mod_rewrite, optimizing .htaccess
• Selection and tuning of MPM (we recommend event)
• PHP-FPM pool configuration (pm.max_requests, etc.)
• Securing sensitive directories, hardening security
• Composite cache configuration (Bitrix HTML Cache)
• Load testing and report
• Recommendations for server-side caching (Redis/Memcached)

Timeline: from 0.5 to 1 day. Cost is calculated individually—contact us for a free project assessment. We guarantee stable operation after configuration—over 7 years of experience and 50+ successful projects.

If you need Apache configuration from scratch or optimization of an existing setup, get in touch. Receive a consultation and a ready-to-use solution for your project.

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.