VPS server security

Putting several websites on one VPS is sensible: it is cheaper, simpler to manage and easier to keep consistent. It also concentrates risk. Once malware reaches the filesystem, the boundary between "the site that got hacked" and "every other site on that machine" is often much thinner than people expect.

How one infected site reaches the others

• Shared filesystem permissions. If sites run as the same user, or directories are world-readable, a webshell dropped into one site can read and write into the others.
• A shared PHP process. Sites running under one PHP-FPM pool share an execution context. Isolating pools per site is a meaningful boundary; many setups never do it.
• Reused database credentials. One set of credentials in several wp-config.php files means reading one gives access to all.
• Privilege escalation. An attacker who gets a shell as the web user, then finds an unpatched kernel or a misconfigured sudo rule, owns the whole machine and every site on it.
• Shared credentials in your own tooling. One SSH key or deployment account across every site collapses the separation you thought you had.

Why per-site security is not enough

A security plugin runs inside one site and sees that site. It does not see the server's cron table, systemd timers, SSH keys, firewall rules, running processes, or the neighbouring site's uploads directory. That is precisely where persistence tends to live, which is why a site can pass its own scan repeatedly while the machine underneath it is still compromised.

What server-level protection covers

1. Every site on the box, not one. Including staging copies, old client sites and the ones nobody remembers.
2. The operating system layer. Cron and systemd persistence, fake system binaries, unexpected SSH keys, unfamiliar listening services.
3. Network exposure. Firewall rules, closing unused ports, SSH hardening — key-only authentication, no root login.
4. Isolation between sites. Separate users and PHP pools so a compromise stays where it started.
5. Execution control. Blocking PHP execution in upload directories across every site on the server.
6. Continuous monitoring. Watching for the reinfection attempts that follow a successful compromise.

Practical hardening for a multi-site VPS

• Run each site as its own system user with its own PHP-FPM pool
• Use distinct database users and passwords per site, with least privilege
• Deny script execution in every uploads and cache directory
• Key-only SSH, root login disabled, and an audit of authorised keys
• A default-deny firewall, opening only what is genuinely needed
• Automatic security updates for the OS, with a real update owner for the apps
• Off-server backups, tested by actually restoring one
• Delete abandoned sites and staging copies rather than leaving them parked

Cloud and managed hosting are not exempt

AWS, Lightsail, cPanel, CloudPanel and GoDaddy VPS products all operate a shared responsibility model: the provider secures the infrastructure, you secure what you run on it. Your provider will keep the hypervisor patched. It will not notice a webshell in your uploads folder or a rogue WordPress administrator.

If you are an agency

Concentrating client sites on one server multiplies the blast radius of a single compromise — one incident becomes several client conversations on the same afternoon. Server-level monitoring and white-label response exist precisely for this; see how we work with agencies.

Related guides