Bitrix Push & Pull Server: Installation and Optimization

When notifications about new tasks, messages, or order status changes don't arrive in Bitrix24, the culprit is almost always an incorrectly configured Push & Pull server.

Without it, the system uses Long Polling, causing delays of 30+ seconds and additional server load. We take on the full configuration of this component: from Node.js installation to integration with the pull module and WebSocket connection testing. Contact us for a free project assessment.

How Push & Pull Works: Architecture and Components

The Push server is a separate Node.js process that maintains persistent WebSocket connections with user browsers. The PHP backend sends messages to the Push server via HTTP, which then broadcasts them to all connected clients. Components:

Why WebSocket Is Better Than Long Polling

WebSocket provides real-time bidirectional communication without constant HTTP requests. In tests, it is 2–3 times faster than Long Polling in delivery speed and reduces CPU load by up to 60%. For online stores, this is critical: an order status change notification arrives instantly, not after 30 seconds. At 5000 concurrent connections, WebSocket uses 60% less memory than Long Polling, significantly saving server resources. According to Bitrix documentation, implementing WebSocket (websockets) in Bitrix can reduce server infrastructure costs by up to 30%.

How to Set Up the Push Server in an Hour

Installing Node.js LTS and the bitrix-push-server package takes no more than 15 minutes. Configuration takes another 10 minutes, nginx setup 5 minutes. The remaining time goes to Bitrix integration and testing. In complex cases (e.g., clustering), the process may take up to 3 days.

Installing Node.js (LTS)

Use the official NodeSource repository for the LTS version:

curl -fsSL https://deb.nodesource.com/setup_20.x | bash -
apt-get install -y nodejs
node --version  # v20.x.x
npm --version

Configuring the Push Server

Install the Bitrix Push Server package via npm or download from marketplace.1c-bitrix.ru. Example configuration file /etc/bitrix/push-server.json:

{
    "security": {
        "key": "SECRET_KEY_HERE"
    },
    "server": {
        "port": 8893,
        "hostname": "0.0.0.0"
    },
    "serverHTTPS": {
        "port": 8894,
        "hostname": "0.0.0.0",
        "key": "/etc/ssl/private/site.key",
        "cert": "/etc/ssl/certs/site.crt"
    },
    "log": {
        "level": "info",
        "file": "/var/log/bitrix-push-server.log"
    }
}

SECRET_KEY_HERE is a long random string. Use this same key in the Push module settings in Bitrix.

Configuring nginx for WebSocket Proxying

The Push server listens on ports 8893 (HTTP) and 8894 (HTTPS). Add to your nginx configuration:

location /bitrix/subws/ {
    proxy_pass http://127.0.0.1:8893/bitrix/subws/;
    proxy_http_version 1.1;
    proxy_set_header Upgrade $http_upgrade;
    proxy_set_header Connection "Upgrade";
    proxy_set_header Host $host;
    proxy_read_timeout 3600;
    proxy_send_timeout 3600;
}

location /bitrix/sub/ {
    proxy_pass http://127.0.0.1:8893/bitrix/sub/;
    proxy_http_version 1.1;
    proxy_set_header Host $host;
    proxy_read_timeout 3600;
}

location /bitrix/rest/ {
    proxy_pass http://127.0.0.1:8893/bitrix/rest/;
    proxy_set_header Host $host;
}

Integration with the Pull Module in Bitrix

In the administrative interface: Settings → Product Settings → Module Settings → Push and Pull. Specify:

• Public path: https://yoursite.ru/bitrix/
• Private path: http://127.0.0.1:8893/bitrix/
• Signature key: the same SECRET_KEY_HERE

After saving, check in the browser (DevTools → Network) — WebSocket connections to /bitrix/subws/ should appear.

Auto-Start via systemd

Create /etc/systemd/system/bitrix-push.service:

[Unit]
Description=Bitrix Push Server
After=network.target

[Service]
Type=simple
User=www-data
ExecStart=/usr/bin/bitrix-push-server --config /etc/bitrix/push-server.json
Restart=always
RestartSec=5

[Install]
WantedBy=multi-user.target

Start it: systemctl enable bitrix-push && systemctl start bitrix-push.

What’s Included in Turnkey Setup

• Audit of current server and Bitrix configuration
• Installation of Node.js LTS and the bitrix-push-server package
• Creation of a configuration file with a unique security key
• Configuration of nginx for WebSocket proxying (HTTP and HTTPS)
• Integration of the pull module in the Bitrix admin panel
• Setup of auto-start via systemd
• Testing of WebSocket connections and notifications
• Delivery of documentation and access details

Common Mistakes When Setting Up the Push Server

• Security key mismatch between config and Bitrix settings
• Firewall blocking ports 8893/8894
• Missing mod_proxy_wstunnel module in nginx
• Incorrect public path (must end with /bitrix/)
• Using an outdated Node.js version (below 18)

Comparison: WebSocket vs Long Polling

Our Work Process

1. Analysis — we study your current architecture and load.
2. Design — we determine the optimal configuration (ports, keys, nginx).
3. Deployment — we install and configure the Push server.
4. Testing — we verify all real-time scenarios (chats, notifications, cart).
5. Documentation — we deliver final configs and instructions.

Estimated Timelines and Cost

Setup takes from 1 to 3 business days depending on infrastructure complexity. Cost is determined after analysis of your project. Our team has 10+ years of experience configuring Bitrix and 40+ successful projects. The price includes a 14-day warranty on operation.

For more on WebSocket technology, see Wikipedia.

Order a turnkey Push server setup — get a free consultation and project assessment.

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.