Deploying Self-Hosted Bitrix24 on AWS, Azure, or a Private Cloud

Why Choose IaaS Over Bitrix24 Cloud

The hosted (SaaS) version of Bitrix24 is convenient, but organisations in regulated industries or in regions with strict data-residency requirements often need a self-hosted setup. Based on our project work, the most common drivers are:

• Data sovereignty — keeping CRM data inside a specific country or jurisdiction
• Integration depth — running custom REST handlers, background cron jobs, or tight ERP connections that require server-level access
• User scale — a perpetual "Corporate Portal" on-premise licence becomes more cost-effective than a per-user SaaS subscription beyond ~50 seats
• Security policy — restricting portal access to a fixed IP allowlist or internal VPN, which is impossible on the shared cloud

For a broader comparison of on-premise versus SaaS trade-offs, see Self-Hosted CRM: Why Choose Bitrix24 On-Premise for Data Sovereignty.

---

Minimum and Recommended Server Specifications

Bitrix24's on-premise edition ("Corporate Portal") has published prerequisites that align closely with what we see in production audits. A portal audited by our team had 47 GB RAM and 16 CPU cores and was rated "excellent" by the platform's own System Check tool — that gives a useful upper-bound reference for a medium-sized portal with a ~28 GB database.

Parameter	Minimum (up to ~50 users)	Recommended (50–200 users)
CPU	4 cores (e.g. Intel Xeon E3 class)	8–16 cores
RAM	8–12 GB DDR4	32–64 GB
Storage (OS + app)	40 GB SSD	100+ GB SSD
Storage (DB files)	64–128 GB SSD	256 GB+ NVMe
OS	CentOS Stream 9 / Ubuntu 22.04 LTS	Same
Web environment	Bitrix Web Environment 9.x	Latest stable

Cloud instance mapping (approximate): - AWS: t3.xlarge (4 vCPU / 16 GB) as a starting point; m6i.2xlarge or r6i.2xlarge for production - Azure: Standard_D4s_v5 or Standard_E4s_v5 for RAM-heavy workloads - Private cloud / Hetzner: a dedicated AX41-NVMe or equivalent bare-metal tier

The Bitrix Environment installer (bitrix-env-9.sh) sets up nginx + Apache, PHP, Percona MySQL, and push-server in one pass. Always use the latest version of the VM image shipped by 1C-Bitrix to avoid immediately inheriting outdated packages.

---

Provisioning the Instance: Step-by-Step

The diagram below shows the overall provisioning flow from infrastructure to a live portal.

The flow starts at your cloud console (AWS/Azure/private), proceeds through OS and environment setup, then through Bitrix24 installation and configuration, and finally exposes the portal to end users behind DNS and an SSL certificate.

flowchart TD
    A[Cloud Console<br/>AWS / Azure / Private] --> B[Provision Linux VM<br/>CentOS Stream 9 / Ubuntu 22.04]
    B --> C[Run bitrix-env installer<br/>nginx + Apache + PHP + Percona]
    C --> D[Install Bitrix24<br/>Corporate Portal]
    D --> E[Register licence key<br/>1C-Bitrix cabinet]
    E --> F[Configure DNS<br/>e.g. crm.yourdomain.com → server IP]
    F --> G[Issue SSL cert<br/>Let's Encrypt / ACM]
    G --> H[Configure SMTP<br/>outbound system mail]
    H --> I[Enable Push & Pull<br/>for chat and real-time]
    I --> J[Firewall rules<br/>80, 443 open; 22 restricted]
    J --> K[Portal live — hand off to users]

Key provisioning steps in detail

1. Create the VM — assign a static public IP (Elastic IP on AWS, Static IP on Azure). Note both IPv4 and IPv6 addresses for DNS records.
2. SSH access — use key-based authentication for root; disable password login in sshd_config.
3. Run the Bitrix Environment script — the installer accepts hostname and MySQL root password as flags: ./bitrix-env-9.sh -s -p -H <hostname> -P -M '<strong_mysql_password>'
4. Remove test data — the fresh install includes demo content; delete it before registering the licence.
5. Register the licence key in the 1C-Bitrix personal cabinet using the company's legal details.
6. Enable Push & Pull — required for real-time chat, notifications, and several CRM automation features.
7. Back up on day one — configure automated snapshots to the same server or, better, to an object store (S3 / Azure Blob) before any users log in.

For context on what the implementation scope typically looks like end-to-end, see Bitrix24 Implementation Cost & Timeline: Real Data from 1,300+ Projects.

---

DNS, SSL, and SMTP Configuration

DNS

Create a subdomain pointing to your server IP — the most common pattern is crm.yourdomain.com. You need both an A record (IPv4) and, if your cloud assigns one, an AAAA record (IPv6). Propagation typically takes 15–60 minutes.

SSL

The Bitrix Environment supports Let's Encrypt natively and handles auto-renewal. For AWS, you can alternatively front the instance with an Application Load Balancer and attach an ACM certificate — the ALB terminates TLS and forwards plain HTTP to the EC2 instance on port 80 over the private subnet.

SMTP

Bitrix24 on-premise sends system email (invitations, notifications, password resets) via msmtp — a lightweight MTA relay. Configuration lives at /home/bitrix/msmtp_<domain>.log and supports any SMTP relay with STARTTLS or SSL on port 587 / 465. You must supply:

• SMTP host and port
• Authenticated sender address and password
• tls on and, in production, tls_certcheck on

Use a dedicated transactional email address (e.g. no-reply@yourdomain.com) rather than a personal mailbox. Shared GMail app passwords work for low volumes but a dedicated SMTP relay (SendGrid, Amazon SES, Postmark) is recommended for production.

---

Firewall and Network Architecture

On AWS, use Security Groups; on Azure, use NSGs. The following rules cover a standard deployment:

Port	Protocol	Source	Purpose
443	TCP	0.0.0.0/0	HTTPS (portal)
80	TCP	0.0.0.0/0	HTTP → redirect to 443
22	TCP	Admin IPs only	SSH management
3306	TCP	localhost only	MySQL (never expose publicly)
8895	TCP	localhost / internal	Push & Pull server

For maximum security, place the database on a private subnet with no public route, and expose only ports 80/443 through a load balancer or security group. If your users connect from fixed office IPs, consider restricting the admin panel (/bitrix/admin/) to those IPs only — this is straightforward to enforce at the security group level and significantly reduces the attack surface.

---

Security Hardening Checklist

Security audits we've conducted on production Bitrix24 servers consistently surface the same gaps. Use this checklist before going live:

• [ ] Disable PHP error display — set display_errors = Off and display_startup_errors = Off in php.ini; leaked stack traces expose file paths and DB structure
• [ ] Harden MySQL — disable query_cache, disable local_infile, increase innodb_log_file_size (64 MB is too low; aim for 256–512 MB), tune join_buffer_size and sort_buffer_size
• [ ] Enable HSTS — add Strict-Transport-Security header in nginx config and enforce HTTP→HTTPS redirect
• [ ] Enable 2FA — use Bitrix24's built-in OTP module for all admin accounts
• [ ] Restrict admin panel by IP — allowlist known administrator IPs in the Proactive Protection settings or at the firewall level
• [ ] Enable web antivirus — Bitrix24's built-in web antivirus adds latency but catches a broad class of injection attempts
• [ ] Enable frame protection — prevents clickjacking via the "Protect against framing" setting
• [ ] Keep the platform updated — run core and module updates from the admin panel; outdated modules are the most common audit finding
• [ ] Audit core modifications — use the Bitrix24 Quality Monitor (System Check → Core Integrity). In one audited portal, 23 of 109,188 files were modified (0.02%) — a low rate, but all changes must be documented
• [ ] Rotate all default credentials — change MySQL root and bitrix0 user passwords immediately post-install using ALTER USER
• [ ] IP blocklist on the firewall — maintain and regularly update a blocklist of IP ranges showing scan or injection patterns

---

Database Sizing and Tuning

A ~28 GB database is normal for a medium-sized portal (several dozen active users, a few years of CRM history). Key tuning parameters beyond defaults:

innodb_buffer_pool_size = 70–80% of available RAM
innodb_log_file_size    = 256M (minimum; 512M for busy portals)
join_buffer_size        = 4M  (default 32M is wasteful per-connection)
sort_buffer_size        = 4M
query_cache_type        = 0   (disable; causes contention on modern MySQL)
local_infile            = OFF (security hardening)
log_error               = /var/log/mysql/error.log

Always fix database structure errors reported by Bitrix24's System Check before go-live — the tool flags issues that can be auto-corrected, and any remaining manual fixes should be applied before user onboarding begins.

---

Migrating an Existing Portal to a New Cloud Instance

Cloud migrations (e.g. moving from a legacy VPS to AWS or from one region to another) follow a structured sequence. Based on our migration projects, the typical plan looks like this:

1. Provision and configure the new server (environment, SSL, SMTP, firewall) — ~7 hours
2. Snapshot the old server or take a full Bitrix24 backup (files + DB dump)
3. Restore on the new instance — copy files to /home/bitrix/www/, restore DB, update dbconn.php with new credentials
4. Update DNS to point the domain to the new IP
5. Smoke-test all integrations (telephony, ERP, web forms, REST webhooks)
6. Correct any errors surfaced during testing
7. Open to users — decommission the old server after a short parallel-run window
8. Warranty support period — typically one week to one month for issues that did not exist on the old server

The target state is: same domain, same user logins, same functionality — running on updated web environment (e.g. CentOS Stream 9, nginx 1.26, Apache 2.4.62, PHP 8.2, Percona 8.0) with all security hardening applied. Total elapsed time for a straightforward migration is typically 1–2 working days of engineer time, though the calendar window may be longer to accommodate testing.

If you are also moving from a SaaS CRM to self-hosted Bitrix24 at the same time, the migration from Salesforce to Bitrix24 and migration from HubSpot to Bitrix24 guides cover the data-migration layer in detail.

---

Cost Estimates

Costs depend heavily on region, cloud provider, and licence tier. The figures below are indicative and based on patterns from our project archive; exact pricing varies by market.

Component	Typical Range
Bitrix24 Corporate Portal licence (50 users)	~$1,700–$2,000 one-time purchase
Annual renewal (25% of licence cost)	~$430–$500/year
Marketplace subscription (optional modules)	~$400/year
Cloud VM (AWS t3.xlarge equivalent, 24/7)	$90–$180/month depending on region and reserved pricing
Deployment & configuration (partner fee)	$500–$2,500 depending on scope
Annual security audit + hardening	$500–$1,500

Prices converted from RUB figures in our project archive at approximate market rates. Actual costs in UAE (AED), Brazil (BRL), or Portugal (EUR) will differ — contact your regional Bitrix24 partner for a quote.

For a detailed breakdown of implementation budgets across 1,300+ real projects, see Bitrix24 Implementation Cost & Timeline: Real Data from 1,300+ Projects.

---

Before You Start: Pre-Deployment Questionnaire

Before provisioning, gather answers to these questions from the client or internal stakeholders:

• What is the target subdomain for the portal? (e.g. crm.company.com)
• Which cloud region must data reside in? (affects choice of AWS/Azure region)
• How many concurrent users at peak? (determines instance size)
• Which integrations are required on day one? (telephony, ERP, e-signature, SSO)
• Are there fixed IP ranges for admin access restriction?
• Who manages DNS — internal IT or a registrar panel?
• What is the SMTP relay to use for outbound system mail?
• Is there an existing Bitrix24 Cloud portal to migrate from?

A thorough discovery session prevents most post-deployment surprises. Our Bitrix24 Onboarding Questionnaire covers all these points and more in a structured format you can share with stakeholders before the project kicks off.