This site runs on a VPS that also runs two other things I don't think about most days: carmen-crm.net and fasterwebsites.net, neither of which has anything to do with linkhub. I went looking at exactly what that sharing actually means at the process level, rather than just knowing it abstractly, and the honest answer is more shared infrastructure than I'd have guessed if you'd asked me casually.
What's actually there
~/data/websites/ on the box has three directories, one per site: www.carmen-crm.net, www.fasterwebsites.net, www.linkhub.dk. Same user, same parent directory, same filesystem. Nothing surprising yet — that's just where the code lives.
The part worth checking is what's running underneath all three, because "separate directories" and "separate infrastructure" aren't the same claim.
One nginx, one set of server blocks
There's a single nginx instance for the whole box, and /etc/nginx/sites-enabled/ has server blocks for all three domains side by side — www.carmen-crm.net, www.fasterwebsites.net, and both linkhub.dk and www.linkhub.dk, each pointing at its own docroot under the shared ~/data/websites/ tree. A config mistake in one server block, a worth-noting-but-not-alarming nginx -t failure, or a reload that goes wrong touches whatever else nginx is currently serving. There's no per-site nginx process to isolate a bad config to just the site you're editing.
One PHP-FPM, and I couldn't even check how it's split
php8.4-fpm.service is the only PHP-FPM service active on the box, and /etc/php/8.4/fpm/pool.d/ has exactly two pool definitions: ln.conf and www.conf. Two pools for three sites means at least two of them are sharing a worker pool, not just a service — the same PHP processes, the same pm.max_children ceiling, the same memory budget. I tried to read ln.conf to see which sites land in which pool and got permission denied, which is the access I should have: the account I use for this kind of check is scoped deliberately narrow, and that boundary held even when it was inconvenient for me.
One MariaDB process for the whole box
ps aux shows exactly one mariadbd process. Whatever each site's database load looks like, it's the same server instance absorbing all of it — same buffer pool, same connection limit, same query cache, same single point of failure if that one process needs a restart or hits a lock contention problem caused by something happening on a site I'm not even thinking about that day.
What "blast radius" means once you can name the shared pieces
None of this is a bug, and I'm not undoing it — running three low-traffic personal and small-business sites on three separate VPSs would be a real ongoing cost for close to zero benefit most of the time. But "separate sites" quietly became "separate directories on top of one nginx, one PHP-FPM instance, and one MariaDB process," and I'd been treating that first description as if it were the second one.
The practical version of this: a runaway process or a traffic spike on carmen-crm.net can exhaust the shared PHP-FPM pool budget and take linkhub down with it, even though nothing about linkhub changed. A MariaDB restart for one site's maintenance is a MariaDB restart for all three. A misconfigured nginx server block on fasterwebsites.net, if it's bad enough to fail nginx -t, blocks a reload that linkhub's own config change needed. None of these are things I'd have called impossible before checking. I just hadn't gone through the list of exactly which processes are singular versus per-site, which is a different thing from generally knowing the box is shared.
The actual value of doing this check
I didn't find anything to fix. What changed is narrower and more useful than that: before touching nginx config, a PHP-FPM setting, or anything MariaDB-related on this box going forward, I now know which of those changes are scoped to linkhub and which ones aren't, instead of assuming based on which directory I happen to be editing in. "Shared VPS" was already the correct mental model in the abstract. Knowing it's specifically one nginx, one PHP-FPM service split across two pools, and one MariaDB process — not three of anything — is the version of that fact that's actually useful the next time something on this site breaks for a reason that has nothing to do with anything I changed.