Why WordPress is not permitted on our machines

Bitware Labs hosts on dedicated servers, and WordPress is not permitted on them. This surprises people often enough that it is worth writing down properly, because the reasoning is not what most assume. It is not that WordPress is bad software. It is that a hosting policy is a security boundary, and the plugin model puts that boundary somewhere I cannot stand behind.

What I am actually agreeing to

When I host something, I am making a promise about a machine — that it is patched, that I know what runs on it, that if it is compromised I can tell you how and when. That promise is only as good as my ability to know what is executing.

A WordPress install is not one piece of software. It is WordPress plus a dozen plugins, each an independent codebase with its own author, its own release cadence, its own security posture, and full PHP execution rights inside the same process. Installing one is not configuration — it is deploying a stranger's code to production, from an admin panel, with no review step.

And critically: the person who adds the plugin is usually not the person who promised the machine was secure. The site owner clicks install. I carry the consequence. I am not willing to underwrite a boundary that someone else can move at will, from a browser, without telling me.

The vulnerability is rarely in WordPress. It is in the fourth plugin down, abandoned in 2021, that nobody remembers installing.

That is not a rhetorical flourish — it is the consistent shape of the published data year after year. The core project's security team is competent and responsive. The ecosystem around it is tens of thousands of plugins of wildly varying quality, and a plugin that stops being maintained does not announce itself. It keeps working perfectly, which is precisely the problem.

The operational half

Set security aside entirely and it still does not fit how we run machines.

Self-updating code fights configuration management. WordPress updates itself, and its plugins update themselves. The filesystem is mutable by design. That is genuinely a good default for the audience it was built for, and it is incompatible with an estate where I want to know that what is deployed is what I put there. On our machines, application code is not writable by the process serving it.

Performance work goes into undoing. The usual optimisation path for a WordPress site is installing a caching plugin to compensate for the database queries generated by the other plugins, then an optimisation plugin to compensate for the assets they inject. Layers of software whose purpose is to neutralise the cost of layers of software. Every layer is more surface, more to update, more to go wrong at three in the morning.

Debugging is archaeology. When a hand-built site misbehaves I read the code. When a plugin-stack site misbehaves, the first hour is establishing what is even running: which hooks fire in what order, which plugin filtered the output, which one added the header. That hour is billed to someone, and it buys nothing.

The exchange

This policy costs us work. Plenty of perfectly good clients want a WordPress site, and we send them elsewhere, cheerfully — there are hosts who specialise in doing it properly, with the isolation, scanning and update discipline it requires, and that is a real craft. It is simply not the service we offer.

What the constraint buys, for the sites we do host:

• Everything is code we can read. Node, PHP, static — whatever fits the job, but authored or reviewed by us. When something breaks, the debugging starts at the actual fault rather than at "what is installed".
• The serving process cannot write its own code. A whole category of persistence-after-compromise stops being available.
• Sites are fast without a caching layer to make them fast. The page you are reading is one PHP file, one stylesheet and one script. There is nothing to cache because there is nothing slow.
• The update surface is small enough to actually track. Patching a known set of components is a task. Patching an ecosystem is a hope.

The general principle

This is not really about WordPress. It is about who is allowed to change what is executing on a machine, and whether the person carrying the risk is the person making the change.

Any system where deploying third-party code is a two-click operation available to someone who is not responsible for the server has the same shape. WordPress is simply the most common instance, and the one people are most surprised to hear declined.

If you want a site on our machines, it gets built. That is slower to start and considerably cheaper to keep — and I can tell you, at any hour, exactly what is running on it.