Atualização e Manutenção do Bitrix24 On-Premise: Versões, Patches e Boas Práticas

Por Que Manter o Bitrix24 (Alaio) On-Premise Atualizado

Portais self-hosted desatualizados acumulam, em média, três categorias de risco simultâneas: vulnerabilidades de segurança no ambiente de servidor, erros na estrutura do banco de dados e módulos da plataforma defasados - qualquer uma delas pode comprometer a estabilidade ou a integridade dos dados em produção.

Na versão cloud, a Bitrix aplica patches automaticamente. No on-premise, essa responsabilidade é inteiramente do administrador. Portais que ficam meses sem atualização costumam apresentar:

• Ambiente de servidor (SO, nginx, Apache, PHP, MySQL/Percona) em versões com CVEs conhecidas
• Estrutura de banco de dados com erros acumulados que só se manifestam sob carga
• Módulos da plataforma que utilizam APIs descontinuadas, bloqueando atualizações futuras
• Customizações feitas diretamente no core, sem documentação, que quebram silenciosamente

Em auditorias que realizamos, é comum encontrar portais ainda rodando em sistemas operacionais sem suporte ativo - e isso não é exagero: já documentamos casos com web environment várias versões atrás do recomendado pelo fabricante, expondo o portal a riscos desnecessários.

Para entender o impacto financeiro de manter (ou não) a infraestrutura adequada, consulte nossa análise TCO de 3 anos entre Bitrix24 self-hosted e nuvem.

Ambiente de Servidor: Versões Recomendadas vs. Instaladas

O primeiro passo de qualquer manutenção é comparar as versões instaladas com as recomendadas pelo fabricante - a defasagem de qualquer componente do stack pode impedir a instalação de patches da plataforma.

A tabela abaixo ilustra o tipo de defasagem encontrada em um portal real auditado por nossa equipe:

Componente	Versão encontrada	Versão recomendada
Sistema operacional	CentOS Linux 7 (EOL)	CentOS Stream 9
nginx (proxy)	1.20.x	1.26.x
Apache (dinâmico)	2.4.6	2.4.62
PHP	8.1.x	8.2.x
Percona Server (MySQL)	5.7.x	8.0.x
Web environment Bitrix	7.5.1	9.0.x

Operar com SO em fim de vida (EOL) - como CentOS 7 - significa ausência de patches de segurança do sistema operacional, o que invalida qualquer esforço de hardening feito na camada da aplicação.

Ação recomendada: use a imagem de VM oficial do Bitrix24 para novos deployments ou migre o portal para um servidor com o ambiente atualizado. Ao migrar, o fluxo utiliza o mecanismo nativo de backup e restauração da plataforma - preservando banco de dados, configuração e todos os arquivos (anexos de e-mail, chats, CRM etc.).

Veja os requisitos de hardware antes de planejar uma migração de ambiente no nosso guia de dimensionamento de hardware para 50 a 1.000 usuários.

Banco de Dados: Configurações Críticas Antes de Atualizar

Antes de aplicar qualquer atualização da plataforma, o banco de dados precisa ter sua estrutura validada e suas configurações de performance ajustadas - erros estruturais não corrigidos podem corromper dados durante o processo de migração de schema.

Erros de estrutura

O teste nativo de "Verificação do Sistema" do Bitrix24 detecta e reporta inconsistências no schema. Em um caso auditado, foram encontrados 6 erros - 5 corrigíveis de forma automática e 1 exigindo intervenção manual. O objetivo é zerar o contador antes de prosseguir com o update.

Configurações de performance no MySQL/Percona

Parâmetros mal dimensionados aumentam o risco de falhas durante atualizações longas:

Parâmetro	Problema comum	Ação
innodb_log_file_size	Valor muito baixo (ex.: 64 MB)	Aumentar conforme o tamanho da base
query_cache	Habilitado (deprecado no MySQL 8)	Desabilitar
local_infile	Habilitado (risco de segurança)	Desabilitar
join_buffer_size / sort_buffer_size	Sobredimensionados por sessão	Ajustar para valores padrão recomendados

Também é importante desabilitar o display_errors e display_startup_errors no php.ini - deixá-los ativos expõe caminhos de arquivos, queries SQL e informações de configuração interna a qualquer visitante da página de erro.

Auditoria de Arquivos Modificados do Core

O teste "Monitor de Qualidade" do Bitrix24 verifica cada arquivo da plataforma contra checksums oficiais e identifica modificações diretas no core - prática que bloqueia atualizações e cria dívida técnica acumulada.

Em uma auditoria real de um portal com 109.188 arquivos verificados e 90 módulos analisados, encontramos 23 arquivos modificados diretamente no core (0,02% do total), distribuídos em 6 módulos:

• CRM - campos personalizados, requisitos de entidade e tipos de endereço
• IM (mensagens) - templates de messenger e componentes JS de lista recente
• Extranet - página de índice do wizard de instalação
• Location - widget de mapa (config, bundle e source)
• Socialnetwork - scripts de visualização de conteúdo
• Tasks - template do Gantt e lista de templates

O nível geral de modificação foi classificado como BAIXO, mas qualquer arquivo alterado diretamente no core precisa ser documentado, pois será sobrescrito na próxima atualização - desfazendo silenciosamente a customização.

Boas práticas para customizações:

1. Nunca editar arquivos dentro de /bitrix/modules/ ou /bitrix/components/bitrix/ diretamente
2. Usar o mecanismo de override local (/local/) para templates e componentes
3. Utilizar apenas APIs públicas e documentadas em integrações e módulos próprios
4. Documentar toda customização com referência à versão da plataforma em que foi desenvolvida

Incompatibilidades entre customizações e a nova versão são tratadas como escopo separado - não fazem parte do processo padrão de atualização e requerem avaliação e orçamento específicos.

Para entender o que é possível customizar sem tocar no core, veja o artigo sobre customização além dos limites da nuvem no Bitrix24 self-hosted.

Protocolo de Atualização em Ambientes com Customizações

O protocolo correto para ambientes com customizações exige sempre um servidor de testes idêntico ao de produção, onde a atualização é aplicada e validada antes de qualquer mudança no ambiente real.

O fluxo abaixo representa a sequência que aplicamos em projetos de manutenção:

flowchart TD
    A[Auditoria do ambiente\nversões, DB, core] --> B[Backup completo\nbanco + arquivos]
    B --> C[Servidor de testes\nidêntico ao produção]
    C --> D[Aplicar atualização\nno ambiente de teste]
    D --> E[Testes críticos\nCRM, tarefas, integrações,\nbusiness processes]
    E --> F{Erros encontrados?}
    F -->|Sim| G[Corrigir incompatibilidades\nescopo separado]
    G --> E
    F -->|Não| H[Agendar janela\nde manutenção]
    H --> I[Aplicar em produção]
    I --> J[Testes com usuário\nchave do cliente]
    J --> K[Liberar acesso\naos usuários]
    K --> L[Suporte pós-atualização\n5-7 dias]

Funcionalidades a testar obrigatoriamente após cada atualização

• Criação e atualização de tarefas
• CRM - empresas, contatos, negócios
• Sincronização de calendários e ausências
• Integrações com sistemas externos (ERP, e-commerce, telefonia)
• Business processes configurados
• Itens de menu customizados
• Módulos de extranet (se utilizados)

O cliente participa ativamente da fase de testes: valida os fluxos específicos do negócio e reporta divergências dentro de um prazo acordado. Eventuais atrasos causados por essa validação não geram penalidades ao parceiro executor.

Para projetos que envolvem migração de servidor (não apenas atualização de versão), o processo inclui ainda: configuração de SMTP, Push & Pull, SSL/Let's Encrypt e redirecionamento HTTP→HTTPS, além de backup automatizado configurado no servidor de destino.

Checklist de Segurança Pós-Atualização

Após cada ciclo de atualização, um conjunto de verificações de segurança deve ser executado - em auditorias, identificamos consistentemente as mesmas 5 categorias de falha que permanecem abertas mesmo depois de atualizações recentes.

A tabela a seguir, baseada em auditorias reais que realizamos, mostra as recomendações por prioridade:

#	Recomendação	Prioridade	Complexidade
1	Atualizar SO, nginx, Apache, PHP e banco de dados	Crítica	Alta
2	Corrigir erros de estrutura do banco (automático + manual)	Alta	Média
3	Desabilitar display_errors e display_startup_errors no PHP	Alta	Baixa
4	Desabilitar query_cache e local_infile; aumentar innodb_log_file_size	Alta	Média
5	Auditar os 23 (ou mais) arquivos modificados do core	Média	Média
6	Elevar nível de proteção proativa e segurança do grupo admin	Alta	Média
7	Habilitar 2FA para todos os usuários (OTP)	Alta	Baixa
8	Adicionar header HSTS e forçar redirecionamento HTTP→HTTPS	Alta	Baixa
9	Restringir acesso à área administrativa por IP	Alta	Média
10	Atualizar módulos desatualizados via painel administrativo	Média	Baixa
11	Manter blacklist de IPs no firewall atualizada	Média	Média
12	Habilitar proteção contra uso em iframes (clickjacking)	Baixa	Baixa
13	Habilitar web-antivírus do Bitrix (avaliar impacto na performance)	Baixa	Baixa
14	Repetir scan de segurança após todas as correções	Média	Baixa

O scanner nativo de segurança pode falhar ou encerrar prematuramente quando o ambiente está muito desatualizado - corrija primeiro o ambiente e os parâmetros de PHP antes de interpretar seus resultados.

Para um protocolo completo de hardening, consulte nosso checklist de 25 pontos para segurança do Bitrix24 self-hosted.

Quanto Custa um Ciclo de Manutenção Profissional

O custo de um serviço profissional de atualização e manutenção do Bitrix24 on-premise varia conforme o escopo - atualização simples de módulos, migração de servidor com atualização de ambiente ou auditoria completa seguida de hardening têm faixas de preço e prazo muito distintas.

Com base em projetos que executamos, os escopos mais comuns e seus perfis típicos são:

Escopo	Prazo típico	O que inclui
Atualização de módulos + correção de DB	1 semana	Atualização via painel, correção de schema, testes básicos
Migração de servidor + atualização de ambiente	1-2 dias úteis	Novo SO, novo web environment, transferência de dados, SSL, SMTP, Push&Pull
Auditoria de segurança + hardening	1-2 semanas	Relatório de vulnerabilidades, aplicação das correções, novo scan de validação
Atualização completa com customizações	10 dias úteis	Ambiente de teste, análise de compatibilidade, atualização, testes conjuntos, suporte pós

Os valores finais dependem da região, do volume de customizações existentes e da complexidade das integrações - consulte sempre um parceiro certificado para uma estimativa baseada no seu ambiente específico. Veja como os custos de implementação se comparam em nosso artigo sobre custo e prazo de implementação do Bitrix24.

Projetos de manutenção normalmente adotam regime de 50% de adiantamento e 50% após aceite, com suporte garantido por um período definido após a conclusão. Incompatibilidades de customizações descobertas durante o processo são tratadas como escopo adicional, orçadas separadamente e aprovadas antes da execução.

Para ambientes de alta criticidade, considere também estruturar uma estratégia formal de backup e recuperação antes de qualquer janela de manutenção - detalhamos esse tema em nosso guia de backup e disaster recovery para Bitrix24 on-premise.

---

Trabalhar com um parceiro no self-hosting. Quer o controle do Bitrix24 self-hosted sem gerenciar o servidor? A ACP Group implanta e opera para voce - veja Bitrix24 self-hosted gerenciado, planos de suporte e manutencao ou peca um orcamento chave na mao.