OVH Shared Hosting in 2026: What PHP 8.3 Can (and Can't) Run

OVH shared hosting in 2026 runs PHP 8.3 perfectly well for a server-rendered site, but it is not a server you control. You get a managed Apache + PHP container, a document root at /www/, and a fixed menu of versions and limits. You do not get root, you cannot keep a process alive, and your cron schedule is rationed. If your app fits inside "request comes in, PHP renders HTML, request ends," it's an excellent, cheap, durable home. If you need a daemon, a websocket, or Postgres, you've outgrown it. This is the honest map of the territory, drawn from running amplifiedcreations.com on exactly this stack.

What OVH shared hosting can run with PHP 8.3

The short version: anything that is stateless and request-scoped. A classic LAMP-style PHP application, a server-rendered CMS, a static-plus-PHP hybrid, WordPress, Laravel in its more modest configurations, a Cockpit CMS install on SQLite — all fine. We run a no-build-step PHP 8.3 application: requests hit Apache, PHP renders HTML, the response goes back through Cloudflare. No Node process, no PM2, no Redis. The host is doing exactly the one thing shared hosting is good at.

What you actually get on a current OVH shared plan:

• PHP 8.0 through 8.3, selectable, with the common extensions present: pdo_sqlite, pdo_mysql, gd, curl, mbstring, intl, opcache.
• Apache with .htaccess overrides — your rewrite rules, redirects, and headers live here, not in a vhost you can't touch.
• MySQL/MariaDB databases (a capped number depending on plan) and the filesystem, which means SQLite "just works."
• Cron, FTP/SFTP, and SSH on most plans — but SSH that is sharply curtailed compared to a VPS.

That covers the overwhelming majority of content sites, brochure sites, small e-commerce, and CMS-backed marketing sites. It is genuinely enough.

Pin your PHP version with .ovhconfig — don't trust the panel

The single most important file on an OVH shared account is .ovhconfig at the document-root level. It pins the runtime so a panel toggle or an OVH-side default change can't silently move you to a different PHP version between deploys. Ours is five lines:

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

Treat .ovhconfig as code and commit it to your repo. A few field notes earned the hard way:

• container.image=stable64 selects the 64-bit container image. The image generation determines which PHP point-releases and extensions are actually available — if a version "isn't there," the image is usually why.
• http.firewall=none disables OVH's legacy ModSecurity-style application firewall. We disable it because it produced false positives on legitimate POST bodies; if you leave it on, expect to debug mysterious 403s.
• Changes to .ovhconfig are not instant. Propagation can take a few minutes. Don't assume your edit failed because the first reload still shows the old version.

If you only take one thing from this post: the panel dropdown is a suggestion, .ovhconfig is the source of truth.

No root, no long-running processes — design around it

Shared hosting is shared. You are one tenant in a container, so you have no root, no systemd, and no way to keep a process alive between requests. This is the constraint that decides whether the platform fits, so be brutally honest with yourself about it.

Concretely, the following are off the table:

• Daemons and workers. No queue consumer sitting in a loop, no Node server, no Python ASGI app. If you SSH in and start something, the watchdog reaps it. There is no supervisor to restart it.
• WebSockets / SSE held open. Connections are request-scoped and time-limited. Real-time features need an external service (Pusher, Ably, a serverless function elsewhere).
• Installing system packages. No apt, no compiling a custom extension. You use the PHP extensions OVH ships, full stop. If you need imagick and it isn't enabled, you adapt to gd or you leave.
• Custom Apache modules or a tuned php.ini at the system level. You override per-directory via .htaccess and .user.ini, within limits the host allows.

The mental model that keeps you sane: every unit of work must start and finish inside a single HTTP request or a single cron invocation. No state lives in memory between them. We designed our application to be entirely stateless precisely so this constraint never bites — dynamic content lives in the CMS and in SQLite, never in a long-lived process.

Cron on OVH: rationed, not free

You do get cron, and for a stateless PHP app cron is how you do all your "background" work. But the limits are real and you should plan for them:

• The number of cron jobs is capped by plan — often a handful, not unlimited. You will end up multiplexing several logical tasks into one cron entry that calls a dispatcher script.
• Minimum frequency is throttled. Per-minute crons are not guaranteed on shared plans; treat the realistic floor as a few times per hour, and don't build anything that assumes sub-minute precision.
• Each run is wall-clock-limited just like a web request. A cron job is not a place to run a six-hour batch job. Chunk the work, persist progress, and let the next invocation continue.

Our entire scheduled-work footprint is one daily job that prunes generated cache files:

php /www/lib/cache_prune.php

That script deletes generated OpenGraph and resized-image cache files older than 60 days, touching only an explicit allow-list of subdirectories under storage/cache, and returns counts so the cron output is inspectable. Anything heavier than a tidy-up-and-exit task is the wrong shape for shared cron. When we needed real automation — minify, upload, cache purge — we kept it on our own machine in a deploy script, not on the host.

SQLite vs a managed database

This is the decision people overthink. On OVH shared hosting you have two sane options, and the right one is usually the simpler one.

SQLite is a single file on disk read and written by the PHP process. No network round-trip, no credentials, no second service to monitor. We run Cockpit CMS v2 on SQLite and it is the right call for a content site: the read volume is high, write volume is low (an editor saving a post, occasionally), and Cloudflare absorbs most reads before they ever reach PHP. SQLite is excellent for read-heavy, write-rare workloads with one application writing to it.

Where SQLite stops being the answer:

• Concurrent writers. SQLite serializes writes with a file lock. A handful of editors is fine; a high-write transactional app will hit SQLITE_BUSY.
• Backups and portability. Backing up SQLite on shared hosting means copying the file when no write is mid-flight. We snapshot it as part of our routine rather than trusting a hot copy.
• Multi-host scaling. A file on one container's disk doesn't scale to multiple app servers. The day you need that, you've outgrown shared hosting anyway.

OVH's bundled MySQL/MariaDB is the move when you have genuine write concurrency, multiple apps sharing data, or a framework that expects a client/server database. It's a managed service — you don't tune it, you just get a connection string. For most CMS-backed sites it's more than you need; for transactional apps it's the floor.

When to graduate to a VPS

We're advocates for staying on shared hosting as long as it genuinely fits — it's cheap, the host patches the OS, and there's no server for you to leave insecure. But there's a clear line. Move to a VPS the moment your architecture needs something request-scoped PHP can't express. The honest checklist:

• You need a long-running process: a queue worker, a websocket server, a scheduled job finer than cron allows, or anything that must hold state in memory.
• You need software the host doesn't ship: a specific PHP extension, a different runtime (Node, Python, Go) serving traffic, Redis, Elasticsearch, a headless browser for rendering.
• You need real cron precision or many scheduled jobs.
• You've hit SQLite write contention and a managed MySQL doesn't fix the underlying concurrency need.
• You need control over the web server — custom Nginx config, HTTP/3 tuning, your own TLS termination, fail2ban.

The tradeoff is real and goes both ways: a VPS gives you root and removes every limit above, but now you patch the kernel, configure the firewall, and own every 3 a.m. outage. For a site that is fundamentally "render HTML per request," that's a downgrade in reliability and an upgrade in your maintenance burden. We've kept amplifiedcreations.com on shared hosting on purpose.

The short version

• Can it run PHP 8.3? Yes — pin it in .ovhconfig, not the panel.
• Can it run a CMS? Yes — Cockpit on SQLite is ideal for read-heavy content sites.
• Can it run background workers / websockets? No. No root, no persistent processes.
• Is cron usable? Yes, for tidy-up-and-exit tasks — but it's rationed in count and frequency.
• SQLite or MySQL? SQLite for read-heavy/write-rare; managed MySQL for write concurrency.
• When do I leave? The instant you need a long-running process, unshipped software, or web-server control. Then it's VPS time.

Shared hosting gets dismissed as a beginner's tier. It isn't. It's a deliberate constraint, and for a server-rendered site that respects the constraint, it's one of the most reliable and cheapest places you can ship. Know exactly where the walls are, build inside them, and it'll outlast three framework hype cycles.