PHP tem uma característica que atrapalha quem precisa escolher um ambiente: ele roda em quase qualquer lugar. Da hospedagem mais barata ao servidor mais robusto, o código executa.

O efeito colateral é que a conversa sobre servidor para PHP costuma parar em “funciona”. E funcionar é um piso baixo demais para uma aplicação que sustenta um negócio — porque a diferença entre um ambiente adequado e um improvisado não aparece no primeiro dia, aparece na atualização que quebra tudo, no pico que derruba o site ou no dia em que uma vulnerabilidade conhecida é explorada.

Este guia trata do que distingue os dois: versões e ciclo de vida, extensões, configuração de execução e as decisões que mudam quando a aplicação vai para produção.

Comece pela versão — e pelo calendário

É a decisão de maior impacto e a mais negligenciada, então vale começar por ela.

O PHP segue um ciclo previsível: uma nova versão principal é lançada em novembro de cada ano e recebe dois anos de suporte ativo, com correções de bugs e de segurança, seguidos de dois anos de suporte apenas de segurança. Quatro anos no total. Esse formato vale desde uma mudança adotada pelo projeto em 2024 — antes, o ciclo era de três anos.

Um esclarecimento importante, porque o equívoco é comum: o PHP não designa versões LTS. Todas as versões seguem exatamente a mesma janela de quatro anos. Quem procura por “a versão LTS do PHP” está procurando algo que não existe.

A consequência prática: rodar uma versão fora de suporte significa acumular vulnerabilidades conhecidas e não corrigidas, mesmo com a aplicação e as bibliotecas atualizadas. O risco é silencioso — nada quebra, o site continua no ar, e a exposição só se materializa quando alguém a explora.

Como as datas avançam a cada ano, o hábito correto é consultar a página oficial de versões suportadas do PHP na hora de decidir, em vez de assumir que a versão instalada continua adequada. No momento em que este texto foi escrito, por exemplo, o PHP 8.2 estava em suporte apenas de segurança, com encerramento previsto para o fim de 2026 — um prazo que já exige planejamento de quem ainda o utiliza.

Desempenho: por que a versão importa tanto

Atualizar a versão do PHP costuma ser a intervenção de melhor relação entre esforço e resultado em qualquer aplicação, e vale entender por quê.

Cada versão principal traz otimizações no interpretador. Na prática, o mesmo código executa mais rápido e consome menos memória — o que significa mais requisições atendidas pelo mesmo hardware, sem alterar uma linha da aplicação.

Duas condições, no entanto:

• A compatibilidade precisa ser testada. Funções removidas, comportamentos alterados e avisos de descontinuação aparecem entre versões. Um ambiente de homologação resolve isso.
• O ambiente precisa permitir a escolha. Se o provedor define a versão e você não pode alterá-la, o ganho fica fora do seu alcance.

Esse segundo ponto é o primeiro requisito real de um servidor para PHP: poder escolher e trocar a versão, de preferência testando antes.

Extensões: onde a hospedagem genérica falha

PHP funciona por extensões — módulos que adicionam capacidades ao interpretador. Conexão com banco de dados, manipulação de imagens, criptografia, compactação, cache em memória: cada uma vem de uma extensão.

Aplicações modernas dependem de um conjunto delas, e frameworks costumam listar seus requisitos explicitamente. É aí que a hospedagem genérica frequentemente falha: ela oferece o conjunto padrão, mas não o específico que a sua aplicação precisa — e não permite instalar.

Categorias que costumam causar problema:

• Drivers de banco menos comuns, ou versões específicas deles.
• Processamento de imagem, que pode exigir bibliotecas do sistema além da extensão.
• Cache em memória, geralmente indisponível em ambientes compartilhados.
• Extensões de integração exigidas por meios de pagamento ou serviços específicos.

A verificação prática: liste as extensões que a sua aplicação exige — o próprio framework costuma informar — e confirme a disponibilidade antes de contratar, não depois.

Como o PHP executa: o modelo importa

Vale entender o mecanismo, porque ele explica os limites que você vai encontrar.

Diferente de uma aplicação que permanece em memória, o PHP tradicionalmente inicia a execução a cada requisição, processa e encerra. Isso tem uma vantagem real — vazamentos de memória não se acumulam entre requisições — e um custo: o trabalho de inicialização se repete o tempo todo.

Duas peças reduzem esse custo:

Gerenciador de processos. Em vez de iniciar um processo do zero a cada acesso, um conjunto de processos fica disponível para atender requisições. O número desses processos e o modo como eles são criados e encerrados é a configuração que mais afeta o comportamento sob carga.

Cache de código compilado. O PHP compila o código antes de executá-lo. Sem cache, essa compilação se repete a cada requisição. Com ele, o resultado fica em memória e é reaproveitado. O ganho é substancial e a configuração é simples — mas exige acesso ao ambiente, que hospedagens compartilhadas normalmente não oferecem.

As configurações que mais importam em produção

Sem entrar em sintaxe, que varia entre versões e ambientes, os pontos de ajuste que costumam definir o comportamento:

O que ajustar	Por que importa
Número de processos simultâneos	Define quantas requisições são atendidas ao mesmo tempo
Memória por processo	Multiplicada pelos processos, precisa caber na memória do servidor
Tempo máximo de execução	Interrompe processos travados, evitando que ocupem o servidor
Tamanho de upload	Causa comum de falha silenciosa em envio de arquivos
Cache de código	Evita recompilar a aplicação a cada requisição
Exibição de erros	Deve estar desativada em produção e registrada em log
Sessões	Onde ficam armazenadas afeta o comportamento em múltiplas instâncias

A armadilha mais frequente está nas duas primeiras linhas: processos simultâneos multiplicados pela memória de cada um precisa caber na memória disponível, com folga para o banco de dados e o sistema. Configurar muitos processos em um servidor apertado leva ao esgotamento — e o sistema operacional passa a encerrar processos, produzindo falhas intermitentes difíceis de diagnosticar.

Sobre exibição de erros: mensagens detalhadas em produção expõem caminhos de arquivos, trechos de configuração e, às vezes, credenciais. É uma falha de segurança comum em aplicações publicadas às pressas.

Segurança específica de PHP

Além do que vale para qualquer servidor, alguns pontos são próprios da linguagem:

1. Versão em suporte, pelo motivo já explicado.
2. Dependências atualizadas. Aplicações modernas usam bibliotecas de terceiros, e vulnerabilidades nelas são tão relevantes quanto no próprio PHP. Ferramentas de verificação de dependências resolvem boa parte disso automaticamente.
3. Arquivos de configuração fora da pasta pública. Credenciais em arquivos acessíveis pela web são um erro que ainda acontece.
4. Execução restrita em diretórios de upload. Se um invasor consegue enviar um arquivo e executá-lo, o restante das camadas de segurança perde efeito.
5. Funções perigosas desabilitadas, quando a aplicação não precisa delas.
6. Permissões de arquivo adequadas, sem gravação desnecessária.

Aplicações legadas: o caso mais comum e mais difícil

Uma parte relevante do PHP em produção é código antigo, que funciona e que ninguém quer tocar. Vale tratar disso com honestidade, porque a recomendação padrão — “atualize” — nem sempre é aplicável de imediato.

Quando a aplicação não roda em versões atuais, existem caminhos intermediários:

• Isolar o ambiente, mantendo a aplicação legada separada do restante da infraestrutura, com acesso restrito.
• Atualizar por etapas, corrigindo incompatibilidades uma versão por vez em vez de saltar várias.
• Limitar a exposição, colocando a aplicação atrás de camadas de proteção e restringindo o acesso ao necessário.
• Planejar a substituição, quando o custo de manter supera o de reescrever.

O que não é um caminho: deixar a aplicação em uma versão fora de suporte, exposta à internet, sem nenhuma dessas medidas. Existe suporte estendido comercial para versões encerradas, oferecido por terceiros, mas é uma solução para ganhar tempo — não para substituir a atualização.

O que o ambiente precisa oferecer

Consolidando, um checklist:

• É possível escolher e trocar a versão do PHP?
• As extensões que a aplicação exige estão disponíveis — e é possível instalar outras?
• Existe cache de código compilado ativo?
• É possível ajustar processos simultâneos, memória, tempo de execução e tamanho de upload?
• Há ambiente de homologação para testar mudanças de versão?
• É possível instalar dependências pela linha de comando?
• Tarefas agendadas podem ser executadas em linha de comando?
• Os erros vão para log em vez de serem exibidos ao visitante?

Aplicações simples encontram tudo isso em uma boa hospedagem de sites. Aplicações com extensões específicas, ajuste fino de desempenho ou processos em segundo plano normalmente precisam de um servidor com acesso root.

Conclusão

Que PHP rode em quase qualquer lugar é uma vantagem da linguagem e uma armadilha na hora de escolher o ambiente. A pergunta útil não é se a aplicação executa, e sim se o ambiente permite mantê-la em uma versão suportada, instalar o que ela exige e ajustar a configuração à carga real.

Três decisões concentram a maior parte do resultado: manter a versão dentro da janela de suporte, garantir que o cache de código esteja ativo e dimensionar processos simultâneos pela memória disponível. Nenhuma delas exige reescrever a aplicação.

Se a sua aplicação depende de extensões específicas ou de configuração própria, o requisito é um ambiente que você controle. Conheça o Cloud Server para PHP da TBF Host e avalie a configuração adequada ao seu projeto.

Perguntas frequentes

Qual versão do PHP devo usar em produção?

Uma versão dentro da janela de suporte do projeto. O PHP oferece dois anos de suporte ativo, com correções de bugs e segurança, seguidos de dois anos de suporte apenas de segurança. Como as datas avançam a cada ano, vale consultar a página oficial de versões suportadas antes de decidir, em vez de assumir que a versão instalada continua adequada.

Existe versão LTS do PHP?

Não. O PHP não designa versões de suporte de longo prazo: todas seguem a mesma janela de quatro anos, sendo dois de suporte ativo e dois de suporte apenas de segurança. Quem procura por uma versão LTS do PHP está procurando algo que o projeto não oferece.

O que acontece se eu usar uma versão de PHP sem suporte?

A aplicação continua funcionando, mas o interpretador deixa de receber correções de segurança. Vulnerabilidades descobertas depois do fim do suporte permanecem abertas, mesmo com a aplicação e as bibliotecas atualizadas. O risco é silencioso: nada quebra até que alguém explore a falha.

Atualizar a versão do PHP deixa o site mais rápido?

Costuma deixar. Cada versão principal traz otimizações no interpretador, de modo que o mesmo código executa mais rápido e consome menos memória, atendendo mais requisições com o mesmo hardware. É preciso testar a compatibilidade antes, porque funções removidas e comportamentos alterados aparecem entre versões.

Por que minha aplicação PHP não funciona em determinada hospedagem?

A causa mais comum é a ausência de alguma extensão exigida pela aplicação ou pelo framework, sem possibilidade de instalá-la. Drivers de banco menos comuns, bibliotecas de processamento de imagem, cache em memória e extensões de integração com meios de pagamento são as que mais faltam em ambientes compartilhados.

O que é OPcache e por que ele importa?

É o cache de código compilado do PHP. Como a linguagem compila o código antes de executá-lo, sem cache essa compilação se repete a cada requisição. Com ele ativo, o resultado fica em memória e é reaproveitado, o que reduz significativamente o trabalho por acesso. A configuração é simples, mas exige acesso ao ambiente.

Quantos processos PHP devo configurar no servidor?

O número de processos simultâneos multiplicado pela memória de cada um precisa caber na memória do servidor, com folga para o banco de dados e o sistema operacional. Configurar processos demais em um ambiente apertado leva ao esgotamento de memória e a falhas intermitentes difíceis de diagnosticar.

O que fazer com uma aplicação PHP legada que não roda em versões novas?

Isolar o ambiente e restringir o acesso, atualizar por etapas em vez de saltar várias versões, limitar a exposição com camadas de proteção e planejar a substituição quando o custo de manter superar o de reescrever. Existe suporte estendido comercial oferecido por terceiros, mas ele serve para ganhar tempo, não para substituir a atualização.