Configuring Automatic Scaling for 1C-Bitrix on Cloud Platforms
We often see projects where a Bitrix site crashes during a promotion. The server can't handle the load, and admins manually spin up copies. Automatic scaling solves this: the number of nodes adjusts automatically—growing under load and shrinking during idle periods. For 1C-Bitrix, this is especially relevant for online stores during sale seasons, event portals, and B2B platforms with daily peaks. Keeping 10 servers for a 3-hour peak is inefficient. Automatic scaling lets you pay only for the resources you actually use. Our experience shows that proper setup reduces infrastructure costs by 2–3 times while maintaining fault tolerance. For example, one client saw costs drop by 40% immediately, and total savings reached 65% after optimization.
Cloud Platforms: Yandex Cloud and VK Cloud
In the Russian segment, the main platforms are Yandex Cloud (Instance Groups) and VK Cloud (Auto Scaling Groups). The architecture mirrors AWS Auto Scaling: virtual machine groups with scaling policies based on metrics (CPU, RPS, memory). How it works:
- Metric Alert (CPU > 70% for 5 minutes)
- Scale-out trigger
- New VM created from golden image
- Cloud-init: install nginx + php-fpm, mount NFS
- Health check: VM added to load balancer
- Traffic distributed to the new node
| Parameter | Yandex Cloud | VK Cloud |
|---|---|---|
| Terraform integration | Official provider support | Limited support |
| Managed Kubernetes | Yes (with autoscaling) | Yes (with manual configuration) |
| Technical support | Standard paid | Included in tariff |
Both platforms provide fault tolerance, but the setup of golden images and cloud-init is identical. A golden image is the standard pattern for stateless architecture. Official Terraform documentation helps with providers.
Why Golden Image Is the Foundation of Autoscaling?
Autoscaling works only if a new VM is ready to accept traffic without manual intervention. The image must include:
- nginx, php-fpm with required extensions for Bitrix
- PHP application code (or a mechanism for fast delivery)
- Script to mount shared storage (
/upload/, cache) - Script to connect to Redis for sessions
- Bitrix configuration with correct DB and Redis parameters
Creating a golden image in Yandex Cloud:
# Launch a base VM, configure manually
# After setup, create a disk snapshot
yc compute disk create --snapshot-id <snapshot-id> --name bitrix-golden
# Create an image from the snapshot
yc compute image create \
--name bitrix-app-v1 \
--source-disk bitrix-golden \
--description "Bitrix 1C-Bitrix app node, PHP 8.1"
Cloud-init: Automatic Configuration on VM Startup
Example cloud-init configuration
Cloud-init runs on the first VM boot. It takes care of environment‑specific settings:
# /etc/cloud/cloud.d/bitrix-init.yaml
#cloud-config
runcmd:
# Mount shared NFS volume
- echo "nfs-server:/srv/bitrix-shared /var/www/html/upload nfs rw,sync,hard,intr 0 0" >> /etc/fstab
- mount -a
# Register the node in consul for service discovery
- |
curl -X PUT http://consul:8500/v1/agent/service/register \
-d '{"name":"bitrix-web","address":"'$(hostname -I | awk '{print $1}')"'"}'
# Warm up PHP OPcache
- php /var/www/html/bitrix/cli/health.php --warmup
# Start services
- systemctl start nginx php8.1-fpm
- systemctl enable nginx php8.1-fpm
Configure Bitrix via environment variables (not hardcoded in the image):
// /bitrix/.settings.php — reads from environment
return [
'connections' => [
'value' => [
'default' => [
'className' => '\\Bitrix\\Main\\DB\\MysqlConnection',
'host' => getenv('DB_HOST') ?: 'mysql-master',
'database' => getenv('DB_NAME') ?: 'bitrix',
'login' => getenv('DB_USER') ?: 'bitrix',
'password' => getenv('DB_PASS') ?: '',
],
],
],
'cache' => [
'value' => [
'type' => 'redis',
'redis' => [
'host' => getenv('REDIS_HOST') ?: 'redis-master',
'port' => (int)(getenv('REDIS_PORT') ?: 6379),
],
],
],
];
We use Redis for session storage. It is 10 times faster than file‑based storage.
Configuring a VM Group in Yandex Cloud (Terraform)
resource "yandex_compute_instance_group" "bitrix_web" {
name = "bitrix-web-asg"
service_account_id = var.service_account_id
instance_template {
platform_id = "standard-v3"
resources {
cores = 4
memory = 8
}
boot_disk {
initialize_params {
image_id = var.bitrix_golden_image_id
size = 50
}
}
network_interface {
subnet_ids = var.subnet_ids
}
metadata = {
user-data = file("cloud-init.yaml")
}
}
scale_policy {
auto_scale {
initial_size = 2
min_zone_size = 1
max_size = 10
measurement_duration = 60 # seconds
warmup_duration = 120 # new VM warmup
cpu_utilization_rule {
utilization_target = 70 # %
}
}
}
deploy_policy {
max_unavailable = 1
max_expansion = 2
}
load_balancer {
target_group_name = "bitrix-target-group"
}
}
How to Deploy Code Without Rebuilding the Image?
Rebuilding the golden image on every deploy is inconvenient. We use a Pull‑on‑start approach: in cloud‑init we add a step to fetch code from an artifact. An environment variable RELEASE_TAG is passed in the VM metadata when the group is created; cloud‑init reads it and downloads the required archive from S3. Deploying becomes just changing the tag in metadata—all new nodes start with the current code.
Here is a step‑by‑step deploy process:
- Build the application artifact and upload it to S3.
- Update the VM group metadata: set the new tag.
- Trigger a rolling update of the group: nodes are recreated one by one with the new tag.
- Verify that all nodes are running the new code.
How to Prepare Bitrix for a Stateless Architecture: Checklist
- Sessions → Redis (not files)
- Cache → Redis or NFS (not local disk)
- Files
/upload/→ NFS or S3 - Temporary files, queues → Redis or DB, not
/tmp/ - Cron jobs → run only on one designated node (not all)
- Bitrix agents → switch to cron mode (
BX_CRONTAB=Y) and run from the designated node -
REMOTE_ADDR→ correctly forwarded viaX-Forwarded-Forfrom the load balancer
A critical point with cron: if Bitrix agents run on all nodes simultaneously, duplication occurs. Set the bx_crontab_nodes parameter in bitrix/.settings.php or restrict cron to the designated node via iptables.
Monitoring and Alerts
Metrics for autoscaling policies:
| Metric | Scale-out threshold | Scale-in threshold |
|---|---|---|
| CPU average across group | > 70% for 3 min | < 30% for 10 min |
| Average response time (p95) | > 2000 ms | < 500 ms |
| nginx request queue length | > 100 | < 10 |
| RPS | > 500 per node | < 100 per node |
What You Get
- Architecture documentation describing all components
- Access to infrastructure and IaC code (Terraform)
- Deploy and update instructions
- Training for your team (2-hour workshop)
- One month of support after commissioning
- Full automation: from VM creation to monitoring
Request an infrastructure audit — we will assess your current architecture and propose a migration plan. Get a consultation with a certified engineer to discuss the details of your project.
Case: a client with peak load of 10,000 RPS. After implementing autoscaling, downtime dropped from 15 minutes to zero. Infrastructure costs decreased by 40% due to turning off idle nodes. Our team’s experience: over 50 successful Bitrix projects, 10+ years in development. We guarantee proven reliability and expert support.
Timelines: basic autoscaling with two nodes—3–4 weeks. Production‑ready setup with IaC, monitoring, and runbook—6–10 weeks.
Source: Wikipedia - Autoscaling (https://en.wikipedia.org/wiki/Autoscaling)