Por que o dimensionamento importa mais no self-hosted
No Bitrix24 self-hosted, o dimensionamento incorreto é a principal causa de falhas: servidores subdimensionados geram timeout em automações e queda no chat em tempo real, enquanto os erros mais frequentes em projetos reais estão em parâmetros de banco de dados mal configurados, PHP desatualizado e ausência de separação de serviços.
Na versão cloud, a 1C-Bitrix gerencia a infraestrutura. Na versão on-premise, a responsabilidade é inteiramente sua — ou do seu parceiro de implementação. Um servidor subdimensionado causa lentidão no CRM, timeout em automações e falhas no Push & Pull (chat em tempo real). Um servidor superdimensionado desperdiça orçamento.
Com base em nossa experiência em projetos de implantação, os problemas mais frequentes não estão na compra do hardware errado, mas em:
- Parâmetros de banco de dados mal configurados (ex.:
innodb_log_file_sizemuito pequeno, Query Cache ativo desnecessariamente) - Ambiente web desatualizado — versões antigas de PHP, nginx ou MySQL introduzem gargalos e vulnerabilidades
- Ausência de separação de serviços — banco de dados, aplicação e armazenamento de arquivos no mesmo disco
Antes de provisionar qualquer máquina, defina três variáveis: número de usuários simultâneos (não apenas cadastrados), volume estimado de dados (CRM + arquivos) e se haverá alta disponibilidade.
Tabela de requisitos por faixa de usuários
A tabela de requisitos indica, por exemplo, que portais com até 50 usuários precisam de 4 vCPUs e 8 GB de RAM, enquanto portais com 501–1.000 usuários exigem 32+ vCPUs, 96–128 GB de RAM e discos NVMe em RAID 10 — valores confirmados por dados reais de produção.
A tabela abaixo reflete perfis de uso típicos: CRM ativo, tarefas, chat e pelo menos uma integração (telefonia ou ERP). Usuários que utilizam apenas o portal de comunicação interna podem reduzir os valores em ~20%.
| Usuários cadastrados | Simultâneos estimados | CPU (vCPUs) | RAM | Disco OS + App | Disco Dados (BD + Arquivos) | Rede |
|---|---|---|---|---|---|---|
| Até 50 | 10–20 | 4 | 8 GB | 40 GB SSD | 100 GB SSD | 100 Mbps |
| 51–100 | 20–40 | 8 | 16 GB | 60 GB SSD | 200 GB SSD | 200 Mbps |
| 101–250 | 40–80 | 12 | 32 GB | 80 GB SSD | 500 GB SSD/NVMe | 500 Mbps |
| 251–500 | 80–200 | 16 | 48–64 GB | 120 GB SSD | 1 TB NVMe | 1 Gbps |
| 501–1.000 | 200–400 | 32+ | 96–128 GB | 120 GB SSD | 2–4 TB NVMe (RAID 10) | 1–10 Gbps |
Referência de projeto: um portal em produção com ~150 usuários ativos opera com 16 vCPUs e 47 GB de RAM de forma estável, com banco de dados de aproximadamente 28 GB — valores que confirmam a faixa de 100–250 usuários da tabela acima.
Software de sistema: versões recomendadas
O stack recomendado atualmente é Ubuntu 24.04, nginx 1.26+, PHP 8.2+ e Percona Server 8.0.41+; usar a imagem de máquina virtual oficial do fabricante é a forma mais segura de garantir esse ambiente sem conflitos de configuração.
O ambiente web é tão importante quanto o hardware. Usar versões antigas de PHP ou MySQL cria gargalos e brechas de segurança. A tabela abaixo lista o stack recomendado atualmente:
| Componente | Versão mínima aceitável | Versão recomendada atual |
|---|---|---|
| Sistema operacional | CentOS Stream 8 / Ubuntu 22.04 | CentOS Stream 9 / Ubuntu 24.04 |
| Servidor proxy | nginx 1.22 | nginx 1.26+ |
| Servidor dinâmico | Apache 2.4.50 | Apache 2.4.62+ |
| PHP | 8.1 | 8.2+ |
| Banco de dados | MySQL 8.0 / Percona 8.0 | Percona Server 8.0.41+ |
A forma mais segura de garantir o stack correto é usar a imagem de máquina virtual oficial fornecida pelo fabricante do Bitrix24, sempre na versão mais recente disponível. Isso elimina conflitos de configuração e simplifica futuras atualizações.
Parâmetros críticos do MySQL/Percona
Para portais com 100–500 usuários, os parâmetros críticos do MySQL incluem innodb_buffer_pool_size em 70% da RAM, innodb_log_file_size de 512 MB, Query Cache desativado e local_infile = 0 — erros nesses itens são a causa mais recorrente de lentidão encontrada em auditorias.
Hardware adequado não resolve se o banco de dados estiver mal configurado. Em auditorias de portais com problemas de desempenho, encontramos recorrentemente os mesmos erros:
innodb_log_file_sizedefinido em 64 MB (o padrão) — para portais médios e grandes, o valor recomendado é de 256 MB a 1 GBquery_cache_type = ON— o Query Cache é obsoleto no MySQL 8.x e deve ser desativadolocal_infile = ON— representa risco de segurança e deve ser desabilitadojoin_buffer_sizeesort_buffer_sizeem 32 MB ou menos — ajuste conforme a carga
Parâmetros de referência para um portal de 100–500 usuários:
innodb_buffer_pool_size = 70% da RAM disponível para o BD
innodb_log_file_size = 512M
query_cache_type = 0
query_cache_size = 0
local_infile = 0
join_buffer_size = 8M
sort_buffer_size = 4M
Arquitetura recomendada por faixa
A arquitetura evolui em 4 estágios: servidor único até 100 usuários, separação do banco de dados até 250, storage dedicado até 500 e balanceador com BD Master-Réplica para 500–1.000 usuários — a partir de 250 usuários, separar serviços é o primeiro passo obrigatório.
O diagrama abaixo ilustra a evolução da arquitetura conforme o número de usuários cresce. Para portais pequenos, um único servidor cobre tudo. A partir de ~250 usuários, separar os serviços é o primeiro passo para ganho de performance e resiliência.
Esta é a progressão típica: servidor único → separação de banco de dados → cluster com réplica de leitura → alta disponibilidade completa com balanceador de carga.
flowchart TD
A["50–100 usuários\nServidor único\n(App + BD + Arquivos)"] --> B["100–250 usuários\nApp Server separado\ndo Banco de Dados"]
B --> C["250–500 usuários\nApp Server + BD dedicado\n+ Storage NFS/NVMe separado"]
C --> D["500–1.000 usuários\nBalanceador + 2 App Servers\n+ BD Master-Réplica\n+ Storage dedicado"]
Para instalações acima de 500 usuários, considere também a separação do servidor de Push & Pull (responsável pelo chat e notificações em tempo real), que gera carga de conexões persistentes independente da carga do CRM.
Para detalhes sobre cluster ativo-passivo e replicação de banco de dados, veja o guia Bitrix24 Self-Hosted High Availability: Master-Replica Cluster Setup.
Armazenamento: tipos, tamanho e crescimento
O armazenamento cresce de 1–5 GB/mês no banco de dados e pode atingir centenas de GB/ano apenas em gravações de telefonia; a recomendação é usar NVMe para BD acima de 100 usuários, separar volumes e planejar expansão com 6 meses de antecedência.
O disco é frequentemente o gargalo esquecido. O Bitrix24 self-hosted armazena:
- Banco de dados MySQL — cresce ~1–5 GB/mês em portais ativos com CRM intenso
- Arquivos de usuários (Drive, anexos, gravações de chamadas) — o maior consumidor; uma única integração de telefonia pode gerar centenas de GB por ano
- Backups locais — idealmente em volume separado ou storage externo
Recomendações práticas:
- Use SSD NVMe para o banco de dados em qualquer faixa acima de 100 usuários
- Separe o volume de dados do volume do sistema operacional
- Monitore o crescimento mensal e planeje expansão com pelo menos 6 meses de antecedência
- Configure backups automáticos — tanto do banco quanto dos arquivos — em destino separado do servidor de produção
Leia mais sobre estratégia completa de backup em On-Premise Bitrix24: Backup & Disaster Recovery Strategy.
Servidores físicos vs. VPS vs. nuvem privada
Não há modelo único ideal: servidores físicos são indicados para 500+ usuários com dados sensíveis, VPS dedicado atende bem de 50–250 usuários com baixo CAPEX, e nuvem pública oferece elasticidade para qualquer tamanho desde que haja equipe DevOps disponível.
Não existe uma única resposta certa — depende do orçamento, dos requisitos de soberania de dados e da capacidade técnica interna.
| Modelo | Prós | Contras | Indicado para |
|---|---|---|---|
| Servidor físico próprio | Custo previsível a longo prazo, controle total | CAPEX alto, manutenção interna | 500+ usuários, dados sensíveis |
| VPS dedicado (hoster) | Baixo CAPEX, escalável | Latência variável, dependência do provedor | 50–250 usuários |
| Nuvem privada (AWS/Azure/GCP) | Elasticidade, SLA gerenciado | Custo mensal pode ser alto | Qualquer tamanho com equipe DevOps |
| Datacenter colocado | Balanceia CAPEX/OPEX | Exige expertise de rede | 250–1.000 usuários |
Para implantações em nuvem pública, confira Deploying Self-Hosted Bitrix24 on AWS, Azure, or a Private Cloud.
Checklist antes de provisionar o servidor
O checklist de 9 itens antes de provisionar cobre desde a definição de usuários simultâneos e módulos até a configuração de backup no primeiro dia de produção — todos os pontos devem ser validados antes de qualquer pedido de hardware ou criação de instância.
Use esta lista antes de fazer qualquer pedido de hardware ou criação de instância:
- [ ] Número de usuários cadastrados e simultâneos estimados definidos
- [ ] Módulos que serão utilizados listados (CRM, Drive, telefonia, intranet, tarefas)
- [ ] Volume inicial de dados e taxa de crescimento estimada
- [ ] Requisito de alta disponibilidade definido (SLA necessário)
- [ ] Tipo de armazenamento escolhido (SSD/NVMe para BD, HDD para backups frios)
- [ ] Stack de software alinhado com a versão atual do ambiente web Bitrix
- [ ] Acesso SSH root disponível para o parceiro de implementação durante o deploy
- [ ] Portas 80, 443 abertas e domínio/DNS configurado antes do início das instalações
- [ ] Backup inicial automatizado configurado no primeiro dia de produção
Para uma análise de custo total de propriedade comparando self-hosted com a versão cloud, veja Self-Hosted vs Cloud Bitrix24: Complete 3-Year TCO Analysis.