One shared hosting login puts ten client sites in a single failure domain

Unique logins close one of the six coupling modes the guide lists. Three of the others are about shared resources: a vulnerable plugin reading or modifying neighbouring files, one traffic spike consuming the account's shared workers or I/O allowance, and a full disk interrupting unrelated databases, logs, sessions and email ^[3][4]. Credential hygiene does nothing for those three. They need a quota something enforces, and the guide's checklist for comparing a WordPress hosting environment asks about PHP limits, web-server behavior, database access, backup tooling and observability ^[12].

The standard is stated as three properties per client: a security boundary, a measurable resource budget, and an independently testable recovery path ^[17]. Four of the seven items in the minimum standard create a per-client or per-person identity, namely a separate hosting account, a unique WordPress administrator identity for each human operator, a unique database user and password per site, and separate SFTP or deployment credentials ^[7][18]. The remaining three are portfolio-wide policy: no password reuse between production, staging, email and the registrar, multi-factor authentication wherever the control plane supports it, and an access-removal checklist for staff and contractors ^[7]. Only the separate account changes what a site can consume, because the PHP limits and the worker pool belong to the account ^[2].

How much isolation the account buys depends on the host. The guide asks for a system user per client environment "where the platform exposes one" ^[8], and says the split does not guarantee perfect isolation because the provider and platform still matter ^[5]. Where no system user is available, the filesystem owner stays shared and the boundary is administrative.

The performance argument rests on one sentence. Every uncached dynamic request occupies a PHP worker until application code, database queries, remote API calls and filesystem operations finish, and when all workers are busy the rest wait ^[9]. So a slow remote API holds its worker for as long as it is slow, while the CPU graph stays flat. The guide draws the consequence directly: a site can report modest average CPU utilization while users experience long tail latency, because the pool is saturated or blocked ^[10].

That is also why a plan sized from monthly page views only transfers between sites with comparable cache-hit ratios. The contrast the guide draws is a mostly cached publication serving large volumes efficiently against a membership site whose authenticated sessions, searches, checkout requests and personalized dashboards generate dynamic work on nearly every request ^[13].

A disclosure at the top says the guide was prepared with AI assistance and reviewed for accuracy and clarity by the EniyiSunucum team ^[14], which is more provenance than most hosting checklists print. No measurements from an actual agency portfolio appear in it ^[19], so the case rests on the coupling list and on the queueing argument.