The web did not actually leave

W3Techs has PHP at roughly seven in ten of the websites whose server-side language can be identified, and WordPress alone sits at around 43 percent of the entire web, with WooCommerce, PrestaShop, and a long tail of agency-built Laravel and Symfony sites stacked on top of that. A meaningful slice of those sites run on shared or cPanel-style managed plans, because for a bakery, a regional law firm, or a two-hundred-client freelance agency, the five-dollar plan is not a compromise, it is the correct amount of hosting, and any software that cannot run there simply does not exist for those buyers.

The industry spent a decade pretending this constraint was gone, since the VPS and container era let developers choose their own runtime and the shared host became something we joked about, but the customers never moved, they just became somebody else’s support ticket.

What the plan actually forbids

A shared host gives you PHP-FPM with a fixed, curated extension list, and the list is the whole story: there is no root, there is no phpize, there is no pecl install, and the best-case escape hatch is a cPanel checkbox grid of prebuilt extensions the host compiled once and will patch on their schedule, not yours. The moment your stack depends on a C extension that is not on that grid, and ext-mongodb is the classic example, the support conversation ends in a shrug or in an upsell to a VPS, and the customer hears “your software needs different hosting” as “your software costs more than you said it would.”

This is not a new problem wearing a new coat; in 2005 it was the entire industry, every PHP app assumed MySQL over localhost because that is what the plan provided, and the dependency tree of the average app was mysql_* plus whatever GD did. We modernized the runtime and forgot that the constraint moved rather than disappeared, from “the host must have MySQL” to “the host must let you compile,” which for a cPanel customer is the same wall painted a different color.

What pure PHP actually ships as

The mongreldb-php client declares three requirements in composer.json, and two of them are not really requirements at all:

"require": {
    "php": ">=8.4",
    "ext-curl": "*",
    "ext-json": "*"
}

ext-json has been compiled into PHP itself since 8.0 and cannot be disabled, and ext-curl ships enabled in every cPanel and shared-host image we have ever met, though honesty demands one caveat: it is the single genuine declared dependency of the package, so a hand-rolled minimal container or the official bare php Docker image may need its php-curl equivalent installed first, while the shared hosts this article is about ship it by default. There is no .so to match against the host’s PHP build, no ABI that snaps when the host bumps 8.4 to 8.5 over a weekend, and no compile step that a support agent has to bless.

Installation is the boring kind of magic:

composer require visorcraft/mongreldb-php

What lands in vendor/ is plain PHP files with a PSR-4 autoloader, which means deployment is an upload; if the plan gives you SSH, Composer runs on the host, and if it does not, you build vendor/ locally and rsync or FTP it up, a workflow older than some of the engineers reading this sentence and one that still works precisely because there is nothing in it that can break. The application code looks like this on any plan that can run PHP at all:

use Visorcraft\MongrelDB\Database;

$db = new Database('https://db.internal.example.com:8453', token: $token);

$db->createTable('orders', [
    ['id' => 1, 'name' => 'id',    'ty' => 'int64',   'primary_key' => true,  'nullable' => false],
    ['id' => 2, 'name' => 'email', 'ty' => 'varchar', 'primary_key' => false, 'nullable' => false],
    ['id' => 3, 'name' => 'total', 'ty' => 'float64', 'primary_key' => false, 'nullable' => false],
]);

$db->put('orders', [1 => 1, 2 => 'alice@example.com', 3 => 49.99]);

Where the database lives, then

The client speaks plain HTTP to a mongreldb-server daemon, and that single fact is what makes the shared-hosting story work, because the daemon does not have to live on the plan at all. It runs wherever you control something: a small VPS, a container next to your other services, a mini PC in the agency’s office closet, and the PHP side stays exactly where the customer’s budget already put it, talking to the daemon over keep-alive connections with a bearer token and an IP allowlist standing in for the old “localhost is the security model” assumption.

In 2005 we colocated MySQL with the app because the network was the trust boundary and the host gave us both on one box; the modern equivalent is a daemon you own on a network you control, and the difference is that the cheap plan no longer has to provide the database for the arrangement to feel just as simple.

The honest part

Shared hosting is not secretly good, and pretending otherwise would be nostalgia rather than engineering: outbound requests share a crowded process pool, nothing long-running survives, and every request pays PHP’s bootstrap cost, so the client does what it can inside those limits, reusing connections through cURL keep-alive and staging writes into idempotent batch transactions so a unit of work costs one round trip instead of five. If the application outgrows the plan, the same code runs unchanged on FPM, FrankenPHP, or a queue worker somewhere serious, because the transport was HTTP the entire time and nothing about the deployment shape is baked into the client.

That is the whole argument, really: a dependency tree is a product decision, every compiled extension you require quietly deletes the slice of the market that cannot or will not compile it, and a pure PHP client deletes none of it, which is why “it runs everywhere PHP runs” is still worth saying out loud in 2026.