Adobe Commerce 2.4.9 requisitos de sistema não devem ser tratados apenas como uma lista para a equipe de infraestrutura. A combinação de PHP, Composer, mecanismo de busca, banco de dados, cache, mensageria e servidor web interfere no deploy, no catálogo, no checkout e nas integrações da loja.
Antes de atualizar, compare a matriz oficial com as versões realmente executadas em produção, homologação, contêineres e pipelines. O roteiro abaixo ajuda a encontrar incompatibilidades sem alterar todos os componentes na mesma janela.
Adobe Commerce 2.4.9 requisitos de sistema: o que mudou na matriz?
A matriz de requisitos lista PHP 8.5, Composer 2.10, OpenSearch 3, MariaDB 12.3 ou 11.8, RabbitMQ 4.3, Valkey 9 e nginx 1.30 entre as dependências testadas para o Adobe Commerce 2.4.9. As versões e observações aplicáveis a cada ambiente devem ser confirmadas diretamente na página de requisitos de sistema do Adobe Commerce.
As notas da versão também informam suporte ao PHP 8.5, compatibilidade com OpenSearch 3.x e suporte a MariaDB 11.8 e 12.x. O mesmo documento registra que PHP 8.2 e PHP 8.3 deixaram de ser suportados a partir do Adobe Commerce 2.4.9, conforme as notas oficiais do Adobe Commerce 2.4.9.
Isso não significa que basta trocar os números nos serviços. Extensões PHP, módulos de terceiros, código personalizado, clientes de banco, imagens de contêiner e ferramentas do pipeline também precisam funcionar com a nova composição.
1. Registre as versões efetivamente utilizadas
Não confie apenas no painel da hospedagem ou no arquivo de infraestrutura. A versão declarada pode ser diferente daquela usada pelo PHP-FPM, pela linha de comando, pelo cron ou pelo processo que executa o deploy.
Em um ambiente autorizado, comandos de leitura como estes ajudam a iniciar o inventário:
php -v
composer --version
bin/magento --version
nginx -v
valkey-server --versionConsulte também a versão do servidor MariaDB com uma conexão administrativa controlada, a versão do cluster OpenSearch e o estado do RabbitMQ. Não publique credenciais, endpoints internos ou a saída completa desses comandos em chamados abertos.
Registre para cada componente: produção, homologação, imagem ou host, versão atual, versão pretendida, responsável, dependências conhecidas e forma de retorno. Essa tabela reduz o risco de homologar uma arquitetura e publicar outra.
2. Valide PHP 8.5 em todos os processos
A mudança do PHP merece atenção porque a loja pode apresentar comportamentos diferentes entre web e CLI. Confirme a versão do PHP-FPM, dos workers, do cron e do terminal utilizado pelo pipeline. Compare também as extensões carregadas e os limites de memória.
Antes de modificar o composer.lock, procure restrições incompatíveis com o PHP pretendido:
composer prohibits php 8.5
composer check-platform-reqsEsses comandos auxiliam o diagnóstico, mas não substituem testes. Um módulo pode aceitar PHP 8.5 em sua restrição de versão e ainda falhar por código descontinuado, tipagem ou comportamento interno. Preserve os resultados e corrija cada pacote de forma controlada.
3. Não transforme a atualização do Composer em atualização geral
O Composer 2.10 aparece na matriz testada do Adobe Commerce 2.4.9, conforme a página oficial de requisitos já citada. Antes do upgrade, confirme qual binário é chamado no terminal e no pipeline, pois usuários ou imagens diferentes podem executar versões distintas.
Evite usar composer update sem delimitação apenas para verificar se o projeto “passa”. Isso pode recalcular pacotes sem relação direta com o upgrade e tornar o rollback mais difícil. Faça uma cópia do projeto, preserve o arquivo de lock e identifique primeiro os conflitos. Se houver bloqueio de dependências, consulte também o guia sobre como descobrir o pacote que impede uma instalação no Magento 2.
4. Homologue o OpenSearch 3 com dados representativos
A compatibilidade informada com OpenSearch 3.x não elimina a necessidade de testar índices, consultas e extensões de busca. Crie a homologação com uma amostra representativa do catálogo, incluindo produtos configuráveis, atributos usados em filtros, sinônimos e diferentes visões de loja.
Depois da indexação, verifique:
- busca por nome, SKU, termos parciais e acentos;
- camadas de navegação e contagem dos filtros;
- produtos simples associados a configuráveis;
- tempo de resposta e erros nos logs;
- extensões de recomendação, merchandising ou busca personalizada.
Não aponte a produção para um cluster recém-migrado sem plano de retorno. A cópia dos dados não comprova que mappings, analisadores e consultas personalizadas continuam compatíveis.
5. Trate MariaDB como migração de dados
MariaDB 11.8 e 12.x aparecem como suportados nas notas do Adobe Commerce 2.4.9, enquanto a matriz testada especifica MariaDB 11.8 ou 12.3. Essa diferença reforça a necessidade de conferir a combinação exata planejada nos requisitos oficiais, em vez de escolher qualquer versão apenas pela família principal.
Faça backup consistente, teste a restauração e registre o tempo necessário para recuperar a base. Na homologação, valide criação de pedido, atualização de estoque, regras de preço, importação, indexação e rotinas de integração. Compare ainda charset, collation, modo SQL, parâmetros de conexão e réplicas, quando existirem.
6. Separe cache, página inteira e sessões ao testar Valkey 9
A matriz testada lista Valkey 9. Antes de mudar o serviço, identifique se a instalação utiliza o mesmo backend para cache padrão, cache de página e sessões ou se existem instâncias separadas. Confirme também os hosts e bancos configurados em cada ambiente.
Teste login, carrinho anônimo, carrinho autenticado, expiração de sessão, Admin e invalidação de páginas após alterações no catálogo. Limpar todo o cache repetidamente pode ocultar um problema de persistência ou roteamento. Para um plano específico de transição, veja as verificações antes de trocar Redis por Valkey.
7. Inclua RabbitMQ e nginx no inventário
RabbitMQ 4.3 e nginx 1.30 também constam entre as dependências testadas na matriz oficial. Mesmo quando a vitrine abre normalmente, uma incompatibilidade na mensageria pode interromper consumidores e acumular tarefas assíncronas.
Verifique consumidores configurados, filas pendentes, reinício dos processos e tratamento de mensagens com erro. No nginx, compare arquivos ativos, limites de requisição, timeouts, encaminhamento ao PHP-FPM e regras de arquivos estáticos. Faça isso sem substituir a configuração de produção por um modelo genérico.
8. Teste os fluxos comerciais brasileiros
A compatibilidade técnica da infraestrutura precisa terminar em testes de negócio. Em homologação, execute jornadas com PIX e cartão, retorno do provedor, antifraude, cálculo de frete, cupons, emissão fiscal e sincronização com ERP quando esses recursos fizerem parte da operação.
Inclua pedidos aprovados, recusados, cancelados e com retorno assíncrono. Para lojas headless ou aplicativos, valide contratos de API, autenticação e mensagens de erro. O checklist de testes de GraphQL e REST antes do upgrade pode complementar essa etapa.
9. Prepare deploy e rollback antes da janela
Não atualize PHP, banco, busca, cache e aplicação simultaneamente sem pontos de controle. Defina a ordem das mudanças, os critérios de aprovação e o momento em que o retorno ainda é seguro.
- preserve código, configurações e artefatos anteriores;
- teste backups e restaurações, não apenas a geração dos arquivos;
- registre tempos de indisponibilidade e de reindexação;
- monitore logs, filas, pedidos e integrações após o deploy;
- não use dados reais de clientes em ambientes desprotegidos.
Conclusão
Auditar os Adobe Commerce 2.4.9 requisitos de sistema significa comparar a matriz oficial com a infraestrutura real e provar que os fluxos comerciais continuam íntegros. PHP, Composer, OpenSearch, MariaDB, Valkey, RabbitMQ e nginx precisam ser avaliados em conjunto, mas atualizados com controle e possibilidade de retorno.
Se sua equipe precisa mapear incompatibilidades, preparar a homologação ou revisar o plano de upgrade, um diagnóstico especializado pode reduzir mudanças improvisadas e preservar as integrações críticas da loja.
Perguntas frequentes
Quais versões do PHP são compatíveis com o Adobe Commerce 2.4.9?
As notas oficiais informam suporte completo ao PHP 8.5 e registram que PHP 8.2 e PHP 8.3 deixaram de ser suportados a partir do Adobe Commerce 2.4.9. Confirme a matriz oficial antes do deploy e valide PHP-FPM, CLI, cron, extensões e módulos.
O Adobe Commerce 2.4.9 exige Valkey no lugar do Redis?
A matriz oficial testada para a versão lista Valkey 9. A equipe deve conferir a documentação aplicável à sua instalação e inventariar separadamente cache, cache de página e sessões antes de migrar o serviço.
Qual versão do OpenSearch usar no Adobe Commerce 2.4.9?
As notas da versão informam compatibilidade com OpenSearch 3.x, e a matriz de requisitos lista OpenSearch 3. A versão exata deve ser confirmada na documentação oficial e homologada com os índices, filtros e extensões da loja.
Composer 2.10 é obrigatório no Adobe Commerce 2.4.9?
Composer 2.10 consta entre as dependências testadas na matriz oficial. Em vez de concluir a compatibilidade apenas pelo número da versão, confira o requisito vigente, o binário usado no pipeline e as restrições registradas no projeto.
Fontes consultadas
As informações atuais mencionadas neste artigo foram verificadas nas fontes abaixo.
