VPS para aplicações PHP no Brasil

Resposta direta

Para hospedar aplicações PHP no Brasil, escolha uma VPS ou Cloud Server com pelo menos 2 vCPUs, 2 GB de RAM, 40 GB de SSD, acesso root, suporte a PHP-FPM, firewall configurável e backup externo. Essa base atende APIs pequenas, painéis administrativos, sistemas em CodeIgniter, Symfony leve, Slim, aplicações legadas e sites PHP próprios com tráfego moderado. Para produção com banco de dados na mesma máquina, prefira 4 GB de RAM e disco SSD ou NVMe, validando a disponibilidade por plano e localidade. A localização do datacenter também pesa: servidores no Brasil tendem a reduzir latência para usuários nacionais, enquanto regiões nos EUA podem ser suficientes para sistemas internos, backoffices e projetos com orçamento mais apertado.

Resumo rápido

• Para produção básica em PHP, comece com 2 vCPUs, 2 GB de RAM e 40 GB de SSD, mas suba para 4 GB se o banco ficar na mesma VPS.
• PHP-FPM com Nginx costuma ser uma combinação eficiente para APIs, painéis e aplicações modernas.
• Apache ainda faz sentido em sistemas legados que dependem de .htaccess, módulos específicos ou regras antigas.
• Banco de dados local simplifica a operação, mas exige mais RAM, backup rigoroso e monitoramento de I/O.
• Datacenter no Brasil ajuda quando o público é nacional e a aplicação faz muitas requisições pequenas.
• SSD ou NVMe melhora tempo de resposta em consultas, cache em disco, uploads e logs intensos, mas não substitui otimização de código.
• Backups precisam ser restauráveis, não apenas existentes. Teste restauração antes de confiar em qualquer rotina.
• Se o foco for outro stack, veja também o guia de VPS para Laravel e a análise de VPS para MySQL e MariaDB no Brasil.

Por que aplicações PHP precisam de uma VPS bem escolhida

Aplicações PHP fora do WordPress e do Laravel costumam ter uma característica em comum: cada projeto carrega decisões próprias de arquitetura. Um sistema em Symfony pode usar workers, Messenger, Redis e deploy por Git. Um painel antigo em CodeIgniter pode depender de PHP 7.4, extensões específicas, regras em .htaccess e conexão direta com MySQL. Um ERP interno escrito há anos pode precisar de biblioteca GD, ionCube, cron jobs a cada cinco minutos e diretórios com permissão de escrita. A VPS entra nesse cenário porque dá controle sobre versão do PHP, extensões, servidor web, cron, filas, logs e banco de dados.

Em hospedagem compartilhada, muitas dessas decisões ficam limitadas pelo painel. Você instala a aplicação, aponta domínio, cria banco e torce para a versão do PHP bater com o código. Isso funciona para sites simples, mas complica quando o projeto exige Composer, tarefas CLI, scripts longos, workers persistentes, cache em Redis ou deploy automatizado. Em uma VPS, o time pode instalar PHP 8.2 e PHP 8.3 lado a lado, manter um pool PHP-FPM por aplicação e ajustar limites como memory_limit, max_execution_time e opcache.memory_consumption conforme o comportamento real do sistema.

PHP moderno não é só hospedagem compartilhada

PHP hoje roda APIs REST, backends de SaaS, painéis de atendimento, sistemas financeiros internos e integrações com filas. Mesmo aplicações sem framework pesado se beneficiam de OPcache, PHP-FPM bem configurado, logs separados por virtual host e isolamento de usuário. Um exemplo prático: um sistema administrativo com 30 usuários simultâneos, relatórios CSV e upload de imagens pode ficar instável em hospedagem compartilhada por causa de limite de processos. Em uma VPS com 2 vCPUs e 4 GB de RAM, é possível reservar 1 GB para banco, ajustar 10 a 20 processos PHP-FPM e manter margem para Nginx, cron e sistema operacional.

VPS tradicional, Cloud Server e cloud instance

VPS tradicional normalmente representa uma máquina virtual em um host físico, com recursos definidos por plano. Cloud Server e cloud instance costumam oferecer provisionamento mais elástico, API, imagens prontas, rede privada e upgrade com menos atrito, mas a implementação varia por provedor. Para o leitor brasileiro, a pergunta prática não é o nome comercial. O ponto é confirmar CPU, RAM, disco, política de backup, tráfego, região disponível e facilidade para redimensionar. LetsCloud, DigitalOcean, Vultr, Linode/Akamai, AWS Lightsail, Hostinger, HostGator e Locaweb podem aparecer no radar, mas preço, localidade, storage e bandwidth precisam ser revisados nas páginas oficiais antes de qualquer decisão de compra.

Configuração mínima para PHP-FPM, Nginx, Apache e banco

A configuração mínima depende menos do framework e mais do padrão de uso. Uma API PHP pequena, com poucas rotas e banco externo, pode rodar em 1 vCPU e 1 GB de RAM para teste, homologação ou MVP inicial. Em produção, essa margem é curta. O ponto de partida mais seguro é 2 vCPUs, 2 GB de RAM e 40 GB de SSD. Essa configuração permite rodar Linux, Nginx ou Apache, PHP-FPM, OPcache, cron jobs, logs e uma aplicação com tráfego moderado. Se MySQL ou MariaDB estiverem na mesma VPS, 4 GB de RAM vira uma recomendação mais realista.

Uma pilha comum para PHP moderno usa Ubuntu LTS ou Debian, Nginx, PHP-FPM, Composer, OPcache e banco local ou gerenciado. Em um projeto Symfony pequeno, por exemplo, 2 vCPUs e 4 GB de RAM suportam uma aplicação administrativa, cache de configuração, logs estruturados e alguns comandos de console. Já um CodeIgniter legado com relatórios pesados pode exigir mais CPU durante geração de PDF ou exportação de planilhas. O uso de CPU aparece em picos, enquanto a RAM fica pressionada por processos PHP-FPM, buffers do banco e cache do sistema operacional.

CPU, RAM e disco para produção básica

Como referência editorial, pense em três faixas. Projetos pequenos podem começar com 2 vCPUs, 2 GB de RAM e 40 GB de SSD. Sistemas com banco na mesma VPS ficam melhor com 2 vCPUs, 4 GB de RAM e 60 a 80 GB de disco. Ambientes com filas, relatórios, uploads frequentes ou múltiplas aplicações pedem 4 vCPUs, 8 GB de RAM e 100 GB ou mais. Esses números não substituem teste de carga, mas evitam o erro comum de subir produção real em plano mínimo e descobrir gargalo no primeiro fechamento mensal.

Também existe um detalhe que muita gente ignora: processos PHP-FPM consomem memória por worker. Se cada processo usa 60 MB em média e o pool permite 30 processos, só o PHP pode passar de 1,8 GB. Some banco, sistema operacional, cache e monitoramento. Por isso, configurar pm.max_children sem medir memória real é arriscado. Uma boa prática é começar conservador, por exemplo 8 a 12 workers em 2 GB, medir consumo com top, htop ou ps, e ajustar com base em tráfego.

Quando separar banco de dados e aplicação

Banco local simplifica instalação, reduz latência interna e baixa custo operacional. Para muitos sistemas PHP, é o caminho inicial. A separação passa a fazer sentido quando o banco consome CPU durante consultas, quando backups travam a aplicação, quando o volume de dados cresce rápido ou quando há exigência de alta disponibilidade. Se o gargalo principal for MySQL ou MariaDB, aprofunde o tema no guia de VPS para MySQL e MariaDB no Brasil, porque tuning de buffer pool, slow query log e rotina de backup muda bastante a recomendação de infraestrutura.

Nginx, Apache ou os dois: como escolher a pilha web

A escolha entre Nginx e Apache não deve virar disputa religiosa. Para aplicações PHP novas, Nginx com PHP-FPM costuma entregar uma base simples, rápida e previsível. Ele lida bem com conexões simultâneas, arquivos estáticos, proxy reverso e TLS. O PHP roda separado no PHP-FPM, com pools configuráveis por site ou aplicação. Essa separação ajuda quando você hospeda duas aplicações na mesma VPS, por exemplo uma API em Symfony usando PHP 8.3 e um painel legado em PHP 8.1, cada uma com usuário, diretório e limites próprios.

Apache continua relevante. Muitos sistemas PHP antigos foram escritos assumindo .htaccess, mod_rewrite, diretivas por diretório e módulos específicos. Migrar tudo para Nginx pode exigir adaptação de regras e testes cuidadosos. Se a aplicação estável gera receita e a equipe não tem tempo para refatorar rotas, Apache com MPM Event e PHP-FPM pode ser uma transição equilibrada. Você mantém compatibilidade com regras antigas e ganha parte dos benefícios de separar execução PHP do servidor web.

Nginx com PHP-FPM

Uma configuração básica de Nginx para PHP-FPM precisa apontar o root para a pasta pública, bloquear acesso a arquivos sensíveis e encaminhar scripts PHP para o socket correto. Em termos práticos, o bloco deve tratar index.php como entrada, negar acesso a .env, composer.json, backups SQL e diretórios privados. Um erro comum é configurar root na raiz do projeto e deixar arquivos internos expostos. Em Symfony, Slim e aplicações customizadas, o ideal é publicar apenas public, web ou a pasta equivalente.

No PHP-FPM, ajuste OPcache desde o início. Valores como opcache.enable=1, opcache.memory_consumption=128, opcache.max_accelerated_files=10000 e opcache.validate_timestamps=1 para ambientes com deploy frequente são um começo razoável. Em produção com deploy controlado, validate_timestamps pode ser ajustado para reduzir checagens, desde que o processo limpe cache no release. Para APIs pequenas, essa configuração já reduz tempo de resposta sem mexer em código.

Apache com MPM Event e PHP-FPM

Apache com mod_php ainda aparece em ambientes antigos, mas não é a melhor escolha para novos deploys. Com PHP-FPM, o Apache atua como servidor web e repassa execução para pools PHP, de forma parecida com Nginx. Essa abordagem melhora controle de processos e permite trocar versões de PHP com menos impacto. Para legados que usam .htaccess, o ganho está na compatibilidade. Ainda assim, revise AllowOverride, permissões e regras de rewrite, porque .htaccess mal escrito pode gerar custo por requisição e esconder redirecionamentos antigos.

Proxy reverso em sistemas legados

Há cenários em que Nginx na frente e Apache atrás resolvem uma migração difícil. O Nginx cuida de TLS, compressão, arquivos estáticos e limites de requisição, enquanto o Apache preserva comportamento do legado. Essa arquitetura usa mais memória, então não combina bem com VPS de 1 GB. Para algo assim, comece em 2 vCPUs e 4 GB de RAM. Se houver uploads grandes, configure client_max_body_size no Nginx e upload_max_filesize e post_max_size no PHP, sempre mantendo limites coerentes para evitar erro intermitente.

Banco de dados, storage e latência para usuários no Brasil

Banco de dados é onde muitas VPS PHP deixam de ser previsíveis. A aplicação pode responder rápido em páginas simples, mas travar em listagens com filtros, relatórios e buscas sem índice. Em PHP, esse problema aparece como tempo alto em requisições, workers presos e fila de conexões. Se MySQL ou MariaDB rodam na mesma máquina, reserve memória para o banco e monitore consultas lentas. Um projeto com 2 GB de RAM pode rodar bem com banco pequeno, mas fica apertado quando o InnoDB buffer pool disputa espaço com PHP-FPM e cache do sistema.

Para MySQL e MariaDB em VPS compartilhada com aplicação, uma configuração inicial conservadora seria innodb_buffer_pool_size entre 512 MB e 1 GB em servidores de 4 GB, slow_query_log ativado e limite de conexões ajustado ao número real de workers PHP. Não adianta permitir 200 conexões no banco se o PHP-FPM aceita 12 workers e a aplicação usa uma conexão por requisição. Em sistemas legados, também vale procurar consultas N+1, SELECT sem índice e relatórios que carregam milhares de linhas em memória.

MySQL, MariaDB e PostgreSQL em VPS PHP

MySQL e MariaDB continuam sendo a dupla mais comum em sistemas PHP, especialmente em CodeIgniter, aplicações próprias e ERPs internos. PostgreSQL aparece com força em Symfony, APIs e sistemas que usam tipos de dados mais ricos. A escolha técnica precisa considerar biblioteca usada, experiência do time e plano de backup. Para a maioria dos legados, trocar banco não compensa. É melhor corrigir índices, charset, collation, rotinas de manutenção e backup. Se o projeto também envolve WordPress em outro domínio, a lógica muda, e o guia de melhor VPS para WordPress cobre pontos específicos de cache de página, plugins e wp-cron.

SSD, NVMe e IOPS na prática

SSD ou NVMe melhora leitura de arquivos, escrita de logs, tabelas temporárias, cache em disco e operações de banco. NVMe costuma oferecer latência e IOPS melhores, mas isso depende do plano, do provedor e da localidade. Não trate NVMe como solução mágica. Uma consulta sem índice continuará ruim em storage rápido, só que talvez um pouco menos dolorosa. Para aplicações PHP com muitos uploads, geração de miniaturas ou importação de CSV, o tipo de disco pesa mais. Para APIs stateless com banco externo, CPU e latência de rede podem pesar mais que disco.

Localidade também muda a experiência. Uma aplicação hospedada em São Paulo ou outra região brasileira pode entregar latência menor para usuários nacionais do que uma instância nos EUA. Na prática, isso afeta sistemas com muitas chamadas pequenas, painéis com várias requisições AJAX e APIs consumidas por apps móveis. Para backoffice usado por poucas pessoas, a diferença pode ser tolerável. Para checkout, atendimento em tempo real ou painel operacional, cada ida e volta de rede se acumula.

Segurança, backups e operação em produção

Subir uma VPS PHP em produção sem rotina de segurança é pedir problema. O básico começa antes do deploy: acesso SSH por chave, login root direto desativado, usuário administrativo com sudo, firewall permitindo apenas portas necessárias, atualizações automáticas de segurança e Fail2ban ou mecanismo equivalente para reduzir tentativas repetidas. Em uma aplicação PHP típica, as portas públicas costumam ser 80 e 443. SSH pode ficar restrito por IP quando a operação permite. Banco de dados não deve ficar exposto na internet sem necessidade clara.

Permissões de arquivo merecem atenção. Diretórios de upload precisam permitir escrita pela aplicação, mas isso não significa liberar permissão 777. O ideal é separar dono do código, usuário do PHP-FPM e grupo de escrita quando necessário. Arquivos como .env, config.php, backups .sql, composer.lock e scripts de deploy não devem ser servidos pelo web server. Em Nginx, crie regras para negar arquivos ocultos e extensões sensíveis. Em Apache, revise .htaccess e configuração do virtual host para evitar exposição acidental.

Hardening inicial da VPS

Um checklist prático de primeira hora inclui atualizar pacotes, criar usuário sem senha, instalar UFW ou nftables, liberar 22 apenas para IPs confiáveis quando possível, liberar 80 e 443, instalar certificados TLS com renovação automática, ativar logs e configurar timezone correto. Também configure unattended-upgrades em distribuições Debian ou Ubuntu, mas acompanhe reinicializações quando houver atualização de kernel. Para PHP, desative funções perigosas apenas se isso não quebrar o sistema, configure expose_php=Off e mantenha display_errors=Off em produção.

Logs precisam existir, mas não podem crescer sem controle. Configure logrotate para Nginx, Apache, PHP-FPM e aplicação. Um sistema legado com erro repetido pode gerar gigabytes de log em poucos dias e derrubar a VPS por falta de disco. Se a aplicação grava logs próprios, padronize retenção. Para projetos com receita, envie logs críticos para um serviço externo ou ao menos copie arquivos para storage separado.

Backups testados e snapshots

Backup não é print de painel. É uma rotina com escopo, retenção e teste de restauração. Em VPS PHP com banco local, faça dump consistente do banco, copie arquivos de upload, versione código em Git e mantenha pelo menos uma cópia fora da própria VPS. Snapshots ajudam em rollback de infraestrutura, mas podem não substituir backup lógico do banco. Alguns provedores oferecem snapshots e backups como produto separado, outros variam por plano e região. Confirme isso no site oficial antes de assumir que está incluso.

Um exemplo simples: dump diário do MySQL às 02:00, compactação com retenção de 7 dias, envio para bucket externo, backup semanal completo dos uploads e teste mensal de restauração em uma VPS de homologação. Parece burocrático, mas salva projetos. Também documente como restaurar: comandos, ordem dos serviços, versão do PHP, permissões e variáveis de ambiente. Quando a pane acontece, ninguém quer descobrir que o backup existe, mas não restaura.

Tabela comparativa de perfis para VPS PHP

A melhor VPS para PHP depende do perfil do projeto, não de uma lista universal de provedores. Uma aplicação interna com 20 usuários não precisa da mesma arquitetura de um SaaS com cobrança recorrente. Um legado em PHP 7.4 tem riscos diferentes de uma API nova em PHP 8.3. Por isso, a tabela abaixo compara perfis de uso e recursos recomendados. Ela não é uma tabela de preço e não substitui validação humana de planos, localidades, tráfego, tipo de disco e condições comerciais.

Perfil de aplicação PHP	Configuração inicial recomendada	Pilha sugerida	Banco de dados	Cuidados principais
API pequena ou painel interno	2 vCPUs, 2 GB RAM, 40 GB SSD	Nginx, PHP-FPM 8.2 ou 8.3, OPcache 128 MB	Externo ou local leve	Limitar workers, configurar TLS, logs e backup de código
CodeIgniter ou sistema legado	2 vCPUs, 4 GB RAM, 60 GB SSD	Apache com PHP-FPM ou Nginx como proxy	MySQL ou MariaDB local	Compatibilidade de PHP, .htaccess, permissões e backup de uploads
Symfony, SaaS pequeno ou ERP web	4 vCPUs, 8 GB RAM, 100 GB SSD ou NVMe	Nginx, PHP-FPM, Redis opcional, workers	MySQL, MariaDB ou PostgreSQL	Filas, cron, slow query log, monitoramento e restauração testada
Produção com tráfego nacional sensível	4 vCPUs ou mais, 8 GB RAM ou mais	Nginx, PHP-FPM, cache, observabilidade	Banco separado ou gerenciado	Latência no Brasil, deploy sem downtime, backup externo e plano de rollback

Na hora de avaliar provedores, olhe além do nome do plano. DigitalOcean, Vultr, Linode/Akamai e AWS Lightsail têm documentação ampla e regiões internacionais conhecidas, mas a latência para o Brasil depende da região escolhida. Provedores nacionais e regionais podem reduzir latência e facilitar cobrança local, mas recursos como NVMe, snapshots, backup automático, bandwidth e suporte variam por oferta. LetsCloud pode entrar na análise quando o projeto precisa considerar regiões próximas do público brasileiro ou operação local, desde que disponibilidade de localidade, storage e recursos seja confirmada no site oficial. Dados de concorrentes e planos foram tratados como voláteis e devem ser revisados com fonte oficial em 2026-07-14 antes de publicação de qualquer comparativo comercial.

Também pense no ciclo de vida. Uma VPS boa para lançamento pode ficar pequena depois de três meses. O ideal é escolher um provedor que permita upgrade sem reinstalação complicada, tenha imagens estáveis, console de recuperação, rede privada quando necessário e documentação clara. Para times com deploy frequente, API e snapshots sob demanda ajudam. Para agências, painel simples e separação por cliente reduzem erro operacional. Para sistemas críticos, o mais relevante é conseguir restaurar, monitorar e escalar sem improviso.

Recomendações por perfil

Dev solo e projetos pequenos

Para dev solo, freelancer ou MVP em PHP, a recomendação prática é começar simples, mas não frágil. Uma VPS com 2 vCPUs, 2 GB de RAM e 40 GB de SSD é suficiente para uma API pequena, um painel administrativo, um site institucional em PHP próprio ou um sistema interno com poucos usuários. Use Nginx com PHP-FPM, OPcache ativado, certificado TLS automático e deploy por Git. Se o banco ficar na mesma máquina, monitore RAM desde o primeiro dia e considere 4 GB quando houver relatórios, uploads ou rotinas cron. Evite hospedar produção e homologação no mesmo diretório. Mesmo em projeto pequeno, mantenha backup externo diário do banco e uma cópia dos uploads.

Agências e times pequenos

Agências e times pequenos costumam hospedar múltiplas aplicações, clientes diferentes e legados com requisitos variados. Nesse perfil, a VPS precisa oferecer previsibilidade e organização. Uma base com 4 vCPUs, 8 GB de RAM e 100 GB de SSD ou NVMe, quando disponível no plano e localidade, permite separar pools PHP-FPM por cliente, configurar virtual hosts independentes e manter banco local para projetos menores. O cuidado é não transformar uma única VPS em gaveta de tudo. Defina limites por aplicação, padronize logs, use usuários separados, documente versões de PHP e mantenha rotina de atualização. Para sistemas com WordPress em paralelo, trate cache, plugins e wp-cron como caso separado, porque a carga é diferente de uma API PHP sob medida.

Produção crítica e sistemas com receita

Quando a aplicação PHP sustenta receita, atendimento, faturamento ou operação diária, a pergunta deixa de ser apenas qual plano contratar. O foco passa a ser continuidade. Comece com 4 vCPUs, 8 GB de RAM e storage rápido, mas avalie banco separado, backup externo, monitoramento de métricas, alerta de disco, deploy com rollback e ambiente de homologação parecido com produção. Se a aplicação usa filas, crons longos ou processamento de arquivos, isole workers e limite concorrência para não derrubar requisições web. Para público brasileiro, teste latência a partir das cidades relevantes para o negócio. Uma VPS no Brasil pode melhorar resposta percebida, mas só um teste com a aplicação real mostra gargalos de banco, DNS, TLS, cache e código.

Sistemas legados que ainda precisam viver bem

Legado não é sinônimo de abandono. Muitos sistemas em PHP 5.6, 7.2 ou 7.4 ainda rodam processos importantes, mesmo quando o time planeja migração. O primeiro passo é mapear dependências: versão exata do PHP, extensões, charset do banco, tarefas cron, bibliotecas pagas, diretórios graváveis e regras de rewrite. Se a versão do PHP já saiu de suporte, isole a aplicação em uma VPS própria, restrinja acesso, aplique firewall e planeje atualização gradual. Evite misturar legado vulnerável com aplicações novas. Para migração, rode um ambiente paralelo com PHP atual, copie banco mascarado e teste telas críticas antes de trocar DNS. Às vezes, manter Apache com PHP-FPM por compatibilidade é mais seguro do que reescrever regras às pressas.

Times que querem padronizar deploy e manutenção

Times com mais de uma aplicação PHP devem pensar em padronização desde cedo. Use imagens base, scripts de provisionamento, Ansible, Docker quando fizer sentido ou pelo menos um documento de instalação repetível. Padronize diretórios, usuário do deploy, versão do PHP, variáveis de ambiente, rotação de logs e comandos de restart. Em uma VPS tradicional, isso reduz erro humano. Em Cloud Server, facilita recriar ambiente em outra região ou outro plano. Também ajuda na segurança: quando todo projeto segue o mesmo padrão, fica mais fácil conferir permissões, backups e certificados. A infraestrutura perfeita não existe, mas uma infraestrutura documentada evita surpresas em plantão, troca de fornecedor e crescimento de tráfego.