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.

Perguntas frequentes

O alojamento partilhado da OVH consegue correr PHP 8.3 em 2026?

Sim. A versão fixa-se com uma única linha num ficheiro .ovhconfig na raiz do site, por exemplo app.engine.version=8.3, e a OVH aprovisiona esse runtime para o domínio. A alteração entra em vigor em poucos minutos e confirma-se com uma página phpinfo().

Posso correr um worker em segundo plano ou um daemon no alojamento partilhado da OVH?

Não. O alojamento partilhado não dá root nem permite processos de longa duração, por isso um worker de fila persistente ou um daemon de websocket será terminado. A alternativa suportada é o agendador cron da OVH a executar um script PHP ou shell num intervalo fixo (até uma vez por minuto na maioria dos planos), o que chega para tarefas em lote, reconstrução de sitemaps e tarefas de polling.

O alojamento partilhado da OVH suporta SQLite?

Sim, o SQLite funciona no alojamento partilhado porque é apenas um ficheiro em disco e vem incluído no PHP fornecido, o que serve para sites de baixo tráfego, caches de leitura intensa e armazenamento de CMS embebidos como o Cockpit. Para tudo o que tenha escritas concorrentes, use antes a base de dados MySQL/MariaDB incluída no plano, já que o SQLite bloqueia o ficheiro inteiro a cada escrita.

O que é que não se pode fazer no alojamento partilhado da OVH?

Não consegue obter root, instalar pacotes de sistema, correr serviços próprios, abrir portas arbitrárias, usar Docker, nem compilar extensões PHP que a OVH não disponibilize. Também partilha CPU e memória com outros inquilinos, por isso processamento pesado de imagem, transcodificação de vídeo ou inferência de ML vão bater nos limites.

Quando devo passar do alojamento partilhado da OVH para um VPS?

Passe para um VPS quando precisar de root, de um processo de longa duração, de uma extensão PHP ou pacote de sistema personalizado, de deploy em contentores ou de CPU e RAM garantidos. Até lá, um plano partilhado bem afinado com PHP 8.3 fixo, cron e SQLite ou MySQL aguenta bem a maioria dos sites institucionais, blogues e pequenos projetos baseados em CMS.

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.