Alojamento Partilhado OVH em 2026: O Que o PHP 8.3 Consegue (e Não Consegue) Correr

O alojamento partilhado OVH em 2026 corre PHP 8.3 perfeitamente bem para um site renderizado no servidor, mas não é um servidor que controla. Recebe um contentor Apache + PHP gerido, uma raiz de documentos em /www/ e um menu fixo de versões e limites. Não tem root, não consegue manter um processo vivo e o seu horário de cron é racionado. Se a sua aplicação cabe dentro de "chega um pedido, o PHP renderiza HTML, o pedido termina", é uma casa excelente, barata e durável. Se precisa de um daemon, de um websocket ou de Postgres, já a ultrapassou. Este é o mapa honesto do terreno, traçado a partir de correr o amplifiedcreations.com exatamente nesta stack.

O que o alojamento partilhado OVH consegue correr com PHP 8.3

Em resumo: tudo o que seja sem estado e limitado ao pedido. Uma aplicação PHP clássica ao estilo LAMP, um CMS renderizado no servidor, um híbrido estático-mais-PHP, WordPress, Laravel nas suas configurações mais modestas, uma instalação do Cockpit CMS em SQLite — tudo viável. Corremos uma aplicação PHP 8.3 sem passo de build: os pedidos chegam ao Apache, o PHP renderiza HTML, a resposta volta através da Cloudflare. Sem processo Node, sem PM2, sem Redis. O alojamento faz exatamente a única coisa em que o alojamento partilhado é bom.

O que realmente obtém num plano partilhado OVH atual:

• PHP 8.0 até 8.3, selecionável, com as extensões comuns presentes: pdo_sqlite, pdo_mysql, gd, curl, mbstring, intl, opcache.
• Apache com sobreposições por .htaccess — as suas regras de reescrita, redirecionamentos e cabeçalhos vivem aqui, não num vhost que não pode tocar.
• Bases de dados MySQL/MariaDB (em número limitado conforme o plano) e o sistema de ficheiros, o que significa que o SQLite "simplesmente funciona".
• Cron, FTP/SFTP e SSH na maioria dos planos — mas um SSH bastante limitado face a um VPS.

Isto cobre a esmagadora maioria dos sites de conteúdo, sites institucionais, pequeno comércio eletrónico e sites de marketing baseados em CMS. É genuinamente suficiente.

Fixe a sua versão de PHP com o .ovhconfig — não confie no painel

O ficheiro mais importante numa conta partilhada OVH é o .ovhconfig ao nível da raiz de documentos. Fixa o runtime para que um botão no painel ou uma alteração de predefinição do lado da OVH não o mova silenciosamente para outra versão de PHP entre deploys. O nosso tem cinco linhas:

app.engine=php
app.engine.version=8.3
http.firewall=none
environment=production
container.image=stable64

Trate o .ovhconfig como código e versione-o no seu repositório. Algumas notas de campo ganhas a custo:

• container.image=stable64 seleciona a imagem de contentor de 64 bits. A geração da imagem determina quais as point-releases e extensões de PHP realmente disponíveis — se uma versão "não está lá", a imagem é normalmente a razão.
• http.firewall=none desativa a firewall de aplicação ao estilo ModSecurity legado da OVH. Desativamo-la porque produzia falsos positivos em corpos de POST legítimos; se a deixar ligada, conte com depurar 403 misteriosos.
• As alterações ao .ovhconfig não são instantâneas. A propagação pode demorar alguns minutos. Não assuma que a sua edição falhou só porque o primeiro reload ainda mostra a versão antiga.

Se só levar uma coisa deste artigo: o dropdown do painel é uma sugestão, o .ovhconfig é a fonte da verdade.

Sem root, sem processos persistentes — desenhe à volta disso

O alojamento partilhado é partilhado. É um inquilino entre vários num contentor, portanto não tem root, não tem systemd e não tem forma de manter um processo vivo entre pedidos. É esta a restrição que decide se a plataforma serve, por isso seja brutalmente honesto consigo próprio.

Concretamente, o seguinte está fora de questão:

• Daemons e workers. Sem consumidor de fila num ciclo, sem servidor Node, sem aplicação Python ASGI. Se entrar por SSH e arrancar algo, o watchdog mata-o. Não há supervisor para o reiniciar.
• WebSockets / SSE mantidos abertos. As ligações estão limitadas ao pedido e ao tempo. Funcionalidades em tempo real precisam de um serviço externo (Pusher, Ably, uma função serverless noutro sítio).
• Instalar pacotes de sistema. Sem apt, sem compilar uma extensão própria. Usa as extensões PHP que a OVH fornece, ponto final. Se precisa de imagick e não está ativada, adapta-se ao gd ou sai.
• Módulos Apache personalizados ou um php.ini afinado ao nível do sistema. Sobrepõe por diretório via .htaccess e .user.ini, dentro dos limites que o alojamento permite.

O modelo mental que o mantém lúcido: cada unidade de trabalho tem de começar e acabar dentro de um único pedido HTTP ou de uma única invocação de cron. Nenhum estado vive em memória entre eles. Desenhámos a nossa aplicação para ser totalmente sem estado precisamente para que esta restrição nunca morda — o conteúdo dinâmico vive no CMS e no SQLite, nunca num processo de longa duração.

Cron na OVH: racionado, não livre

Tem cron, e para uma aplicação PHP sem estado o cron é como faz todo o trabalho "em segundo plano". Mas os limites são reais e deve planeá-los:

• O número de tarefas cron é limitado pelo plano — muitas vezes um punhado, não ilimitado. Vai acabar a multiplexar várias tarefas lógicas numa só entrada de cron que chama um script dispatcher.
• A frequência mínima é limitada. Crons ao minuto não são garantidos em planos partilhados; trate o piso realista como algumas vezes por hora e não construa nada que assuma precisão abaixo do minuto.
• Cada execução está limitada no tempo de relógio tal como um pedido web. Um cron não é o lugar para correr um batch de seis horas. Divida o trabalho, persista o progresso e deixe a próxima invocação continuar.

Toda a nossa pegada de trabalho agendado é uma única tarefa diária que limpa ficheiros de cache gerados:

php /www/lib/cache_prune.php

Esse script apaga ficheiros de cache de OpenGraph e de imagens redimensionadas com mais de 60 dias, tocando apenas numa lista explícita de subdiretórios sob storage/cache, e devolve contagens para que o output do cron seja inspecionável. Qualquer coisa mais pesada do que uma tarefa de arrumar-e-sair tem o formato errado para o cron partilhado. Quando precisámos de automação a sério — minificar, carregar, purgar cache — mantivemo-la na nossa própria máquina num script de deploy, não no alojamento.

SQLite versus uma base de dados gerida

Esta é a decisão que as pessoas complicam demasiado. No alojamento partilhado OVH tem duas opções sensatas, e a certa é normalmente a mais simples.

O SQLite é um único ficheiro em disco lido e escrito pelo processo PHP. Sem ida e volta pela rede, sem credenciais, sem um segundo serviço a monitorizar. Corremos o Cockpit CMS v2 em SQLite e é a escolha certa para um site de conteúdo: o volume de leituras é alto, o de escritas é baixo (um editor a guardar um artigo, ocasionalmente) e a Cloudflare absorve a maioria das leituras antes de chegarem ao PHP. O SQLite é excelente para cargas com muitas leituras e poucas escritas, com uma aplicação a escrever nele.

Onde o SQLite deixa de ser a resposta:

• Escritores concorrentes. O SQLite serializa as escritas com um bloqueio de ficheiro. Um punhado de editores é aceitável; uma aplicação transacional com muitas escritas vai bater em SQLITE_BUSY.
• Cópias de segurança e portabilidade. Fazer backup do SQLite no alojamento partilhado significa copiar o ficheiro quando nenhuma escrita está a meio. Tiramos um snapshot como parte da rotina em vez de confiar numa cópia a quente.
• Escalar em vários servidores. Um ficheiro no disco de um contentor não escala para vários servidores de aplicação. No dia em que precisar disso, já ultrapassou o alojamento partilhado de qualquer forma.

O MySQL/MariaDB incluído na OVH é o passo certo quando tem concorrência real de escritas, várias aplicações a partilhar dados, ou uma framework que espera uma base de dados cliente/servidor. É um serviço gerido — não o afina, apenas recebe uma string de ligação. Para a maioria dos sites baseados em CMS é mais do que precisa; para aplicações transacionais é o mínimo.

Quando passar para um VPS

Defendemos ficar no alojamento partilhado enquanto realmente servir — é barato, o alojamento aplica os patches do SO e não há um servidor que possa deixar inseguro. Mas há uma linha clara. Passe para um VPS no momento em que a sua arquitetura precisa de algo que o PHP limitado ao pedido não consegue exprimir. A checklist honesta:

• Precisa de um processo de longa duração: um worker de fila, um servidor websocket, uma tarefa agendada mais fina do que o cron permite, ou algo que tenha de manter estado em memória.
• Precisa de software que o alojamento não fornece: uma extensão PHP específica, um runtime diferente (Node, Python, Go) a servir tráfego, Redis, Elasticsearch, um browser headless para renderização.
• Precisa de precisão de cron a sério ou de muitas tarefas agendadas.
• Bateu em contenção de escritas do SQLite e um MySQL gerido não resolve a necessidade de concorrência subjacente.
• Precisa de controlo sobre o servidor web — configuração Nginx própria, afinação de HTTP/3, terminação TLS própria, fail2ban.

O compromisso é real e vai nos dois sentidos: um VPS dá-lhe root e remove todos os limites acima, mas agora é você que aplica patches ao kernel, configura a firewall e é dono de cada falha às 3 da manhã. Para um site que é fundamentalmente "renderizar HTML por pedido", isso é uma descida na fiabilidade e uma subida na sua carga de manutenção. Mantivemos o amplifiedcreations.com em alojamento partilhado de propósito.

Em resumo

• Corre PHP 8.3? Sim — fixe-o no .ovhconfig, não no painel.
• Corre um CMS? Sim — Cockpit em SQLite é ideal para sites de conteúdo com muitas leituras.
• Corre workers em segundo plano / websockets? Não. Sem root, sem processos persistentes.
• O cron é utilizável? Sim, para tarefas de arrumar-e-sair — mas é racionado em número e frequência.
• SQLite ou MySQL? SQLite para muitas leituras/poucas escritas; MySQL gerido para concorrência de escritas.
• Quando saio? No instante em que precisa de um processo de longa duração, software não fornecido ou controlo do servidor web. Aí é hora de VPS.

O alojamento partilhado é desvalorizado como uma camada de principiante. Não é. É uma restrição deliberada e, para um site renderizado no servidor que respeita a restrição, é um dos lugares mais fiáveis e baratos onde pode publicar. Saiba exatamente onde estão as paredes, construa dentro delas, e vai durar mais do que três ciclos de hype de frameworks.