Nginx Configuration for 1C-Bitrix: Security, Caching, Composite

Imagine: you've just moved an e-commerce store to a new server, and customers see 404 on catalog pages. Diagnostics show PHP is working, but SEF URLs are not processed. The cause is missing correct try_files in the Nginx configuration. From our experience, 80% of site display problems on Bitrix after changing hosting are due to this. We solve such issues in 1–2 days by providing a ready-made configuration optimized for high loads. Our experience in Bitrix server setup is over 10 years, with more than 300 projects completed. Contact us for a server audit.

Nginx Configuration for Bitrix: try_files Setup

Without a correct try_files, any URL that does not correspond to a physical file returns 404. Bitrix uses a single entry point /bitrix/urlrewrite.php, so all requests must be directed to it. A mistake in passing $is_args$args leads to loss of GET parameters — a typical problem we see in every second project after migration. The correct Nginx configuration for Bitrix includes exactly this approach.

location / {
    try_files $uri $uri/ /bitrix/urlrewrite.php$is_args$args;
}

Official 1C-Bitrix documentation recommends this exact approach.

What Does Nginx Configuration Bring for Security?

Closing service directories is a basic but mandatory measure. Open access to /bitrix/backup/ can lead to leakage of backups with the database, which is critical for compliance with Federal Law 152. We always block these directories.

location ~* ^/bitrix/(backup|modules|php_interface|tools)/ {
    deny all;
    return 403;
}

location ~ /\. {
    deny all;
    return 404;
}

location ~* ^/upload/.*\.php$ {
    deny all;
    return 403;
}

The /upload directory should serve files but not execute PHP — this is a vector for uploading web shells. We additionally enable open_basedir in PHP-FPM for isolation.

Why Static Caching and gzip Are Crucial

Setting expires 30d and immutable allows the browser not to request static files again, reducing server load by up to 70% for repeat visits. This minimizes latency and bandwidth consumption.

location ~* \.(js|css|png|jpg|jpeg|gif|ico|svg|woff|woff2|ttf)$ {
    expires 30d;
    add_header Cache-Control "public, immutable";
    access_log off;
}

immutable tells the browser: the file will not change until expires expires. Works for versioned Bitrix files (/bitrix/cache/css/[hash].css).

gzip Compression

gzip on;
gzip_vary on;
gzip_min_length 1024;
gzip_proxied any;
gzip_comp_level 5;
gzip_types
    text/plain text/css application/json
    application/javascript text/xml application/xml
    image/svg+xml;

Level 5 is a balance between CPU and compression. Levels 7–9 give minimal gain with noticeable CPU load increase. Enabling gzip_vary is mandatory for correct operation with proxy servers.

How to Speed Up Bitrix Using Composite and Nginx

Bitrix Composites store HTML in /bitrix/html_pages/. Nginx can serve these files without PHP, providing a 10–50 times speed boost for unauthenticated visitors. Configured Nginx with Composite delivers pages 10–50 times faster than standard PHP-FPM stack without caching.

location / {
    set $cache_path "/bitrix/html_pages${uri}";
    if (-f "${document_root}${cache_path}.html") {
        rewrite ^ ${cache_path}.html last;
    }
    try_files $uri $uri/ /bitrix/urlrewrite.php$is_args$args;
}

location ~* /bitrix/html_pages/ {
    internal;
    add_header X-Bitrix-Composite "HIT";
}

Combining HTML cache with Nginx achieves performance of up to 10,000 requests per second on a single server. Savings on server loads can be substantial for a high-traffic store — in one project, we reduced infrastructure costs by 30%, translating to approximately $500/month savings.

Case Study: Incorrect try_files (From Our Practice)

A client — an e-commerce store after server migration. All catalog pages returned 404, but the homepage worked. The cause: the config had try_files $uri $uri/ @bitrix; with a named location @bitrix that did not pass $args. Result: the URL /catalog/electronics/?SECTION_ID=5 lost parameters. After fixing to the standard try_files $uri $uri/ /bitrix/urlrewrite.php$is_args$args, everything worked. This error occurs in 30% of projects when migrating from Apache to Nginx.

What's Included in the Nginx Configuration Service

Process of Work

1. Analysis — study current configuration, server architecture.
2. Design — prepare configuration considering information blocks, load, and security requirements.
3. Implementation — apply changes to Nginx, configure PHP-FPM, test on staging.
4. Testing — check all site sections, including SEF URLs, cart, personal account.
5. Deployment — move to production, monitor for 24 hours, then hand over documentation.

Timelines and Cost

Nginx configuration for Bitrix from scratch takes from 1 to 3 days. The typical cost ranges from $800 to $1,500 depending on infrastructure complexity. Includes audit, implementation, testing, and documentation handover. We also offer ongoing support retainers starting at $200/month.

Ready to optimize your Bitrix? Order a turnkey configuration — get a ready-to-deploy config with documentation. We guarantee compatibility with official updates and security. Contact us for an audit.

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.