What is server isolation and why does it matter in shared hosting?

Server isolation is the set of techniques a hosting provider uses to keep each account on a shared server separate from every other account, so that one customer's files, processes, and resources can't be seen, changed, or starved by another. In shared hosting, where hundreds of sites may run on the same machine, isolation is what stops a single hacked WordPress site from spreading malware to its neighbours or reading their database passwords.

When you buy shared hosting, you're renting a small slice of a server that many other people also use. That's what keeps it affordable, but it also means your site's security partly depends on how well your host walls customers off from one another. This article explains what server isolation is, the main technologies hosts use to achieve it, what can go wrong without it, and how to check whether your host does it properly.

What Is Shared Hosting, Really?

On a shared hosting server, many accounts share the same:

• Operating system and kernel
• Web server (Apache, LiteSpeed, or Nginx)
• PHP installation
• Database server
• CPU, memory, and disk

Each account typically has its own Linux user, home directory, and databases. But unless the host adds extra layers, those accounts can still see a surprising amount of each other. Historically, many shared servers ran all PHP code as the same web server user, which meant any script on the server could read any other site's files.

Isolation is the work of making each account behave as if it's on its own private server, even though it isn't.

Why Server Isolation Matters

Stopping Cross-Site Contamination

The biggest risk on a poorly isolated server is cross-account infection. The typical chain looks like this:

1. One site is compromised, usually through an outdated plugin or a weak password.
2. The attacker uploads a web shell, a script that lets them run commands through the browser.
3. They explore the server, reading other accounts' directories.
4. They steal configuration files, such as wp-config.php, which contain database credentials.
5. They infect other sites, injecting malicious code into every writable file they can reach.

With good isolation, the attack stops at step 2. The attacker can damage the compromised account, but they can't see or touch anything else.

Protecting Secrets

Configuration files hold database passwords, API keys, and salts. If another account can read them, your security depends on the least careful customer on the server. Isolation keeps those files private to your account.

Preventing Resource Abuse

Isolation also covers resources. Without limits, one busy or infected site can consume all the CPU, memory, or disk I/O, slowing down or crashing every other site on the server. This is often called the "noisy neighbour" problem. It's partly a performance issue, but it's also a security one: a site under attack or mining cryptocurrency can effectively cause a denial of service for everyone else.

Limiting Information Leakage

Even without write access, being able to list other users, see running processes, or read world-readable files gives attackers useful information. Good isolation hides other accounts from view entirely.

How Hosts Achieve Isolation

No single tool provides complete isolation. Hosts combine several layers.

Separate Linux Users and File Permissions

The foundation is giving every account its own Linux user and making sure files are owned by that user with sensible permissions. Home directories are typically set so other users can't list or read them. On its own, this isn't enough if PHP runs as a shared user, but everything else builds on it.

Running PHP as the Account Owner

This is one of the most important layers. Instead of running every site's PHP code as a single web server user (like nobody or www-data), the host runs each account's PHP processes as that account's own user. Common approaches include:

• PHP-FPM with per-account pools: Each account has its own pool of PHP workers running under its own user.
• suPHP or suEXEC with CGI/FastCGI: Older approaches that switch to the account's user before running scripts.
• LiteSpeed's LSAPI (lsphp): Runs PHP as the account user on LiteSpeed servers.
• mod_ruid2 or mpm-itk: Apache modules that switch user per request, now less common.

When PHP runs as your user, a web shell uploaded to someone else's account runs as their user, and ordinary file permissions stop it from reading your files.

Filesystem Virtualisation (CageFS and Jails)

Even with separate users, a shell or script can still see system files, other usernames in /etc/passwd, and running processes. Filesystem virtualisation gives each account a private view of the server.

• CageFS (part of CloudLinux OS) gives each user a virtualised filesystem containing only their own files and a safe set of system tools. Other users, their processes, and sensitive system files are invisible.
• Jailed shells in cPanel restrict SSH users to a limited environment.
• chroot environments lock SFTP or shell users into a single directory tree.

Resource Limits (LVE and cgroups)

To stop the noisy neighbour problem, hosts limit how much each account can use.

• CloudLinux LVE (Lightweight Virtual Environment) limits CPU, memory, I/O, number of processes, and entry processes per account.
• Linux cgroups provide similar controls on other platforms, often managed through systemd or the hosting control panel.

If your control panel shows CPU, memory, or "entry process" usage graphs with limits, your host is almost certainly using one of these.

PHP Restrictions

Hosts often add PHP-level restrictions, such as:

• open_basedir: Limits which directories PHP scripts can access, usually to the account's home directory.
• disable_functions: Blocks functions that run system commands.
• Per-account php.ini: So one customer's settings don't affect others.

These help, but they're a secondary layer. Relying on them alone, without per-user PHP execution, isn't enough.

Symlink Protection

A classic shared hosting attack involves creating a symbolic link from one account to a file in another account, then asking the web server to follow it. Hosts defend against this with web server settings like Apache's SymLinksIfOwnerMatch, kernel-level protections such as CloudLinux's SecureLinks, and cPanel's symlink race condition protection.

Database Isolation

Each account should have its own database users with privileges only on its own databases. The database server itself should only be reachable locally or from the hosting network, and customers shouldn't be able to list or access other accounts' databases.

Containers and Virtual Machines

Some modern hosts go further and run each account, or each site, in its own container. Containers use Linux namespaces and cgroups to give each site its own process tree, filesystem, and network view. This offers strong isolation at shared hosting prices, and it's common with managed WordPress hosts.

Virtual private servers (VPS) and cloud instances go further still, giving you your own virtual machine with its own kernel. That's the strongest isolation short of a dedicated server, which is why a VPS is often recommended once a site handles sensitive data or significant revenue.

Levels of Isolation Compared

Here's a rough comparison from weakest to strongest:

1. Basic shared hosting (PHP as a shared user): Accounts can often read each other's files. Weak isolation.
2. Shared hosting with per-user PHP and good permissions: Accounts can't normally read each other's files. Reasonable isolation.
3. Shared hosting with CageFS, LVE, and symlink protection: Accounts can't see each other at all, and resources are capped. Good isolation.
4. Container-per-site hosting: Each site has its own process and filesystem namespace. Strong isolation.
5. VPS or cloud instance: Your own kernel and operating system. Very strong isolation.
6. Dedicated server: Your own physical hardware. Complete isolation from other customers.

Even the strongest options share some risk: containers share a kernel, and VPS instances share physical hardware and a hypervisor. But each step up reduces the chance that someone else's mistake becomes your problem.

Signs Your Host Takes Isolation Seriously

You usually can't inspect a shared server's configuration directly, but you can look for clues:

• Your control panel shows resource usage limits, such as CPU, memory, and entry processes, which suggests CloudLinux LVE or cgroups.
• Your host mentions CloudLinux, CageFS, PHP-FPM per account, or container-based isolation in its documentation or sales pages.
• You can't list other users' home directories over SSH or SFTP. Try ls /home in an SSH session; on a well-isolated server you'll see only your own account, or nothing useful.
• Files are owned by your username, including ones WordPress creates during updates, which indicates PHP runs as your user.
• WordPress can update plugins without asking for FTP details, which usually means PHP runs as the file owner.

A quick check over SSH:

whoami
ls -la ~
ls /home
cat /etc/passwd | wc -l

On a CageFS-protected server, /etc/passwd will typically show only system accounts and your own user, not hundreds of other customers.

It's also perfectly reasonable to email your host and ask:

• Does PHP run as each account's own user?
• Do you use CloudLinux with CageFS, or another form of account isolation?
• Are there per-account resource limits?
• How do you protect against symlink attacks?
• If one account is compromised, what stops it affecting others?

A good host will answer clearly. Vague answers or "we're very secure" without detail are a warning sign.

What You Can Do as a Customer

Isolation is the host's job, but you can reduce your own risk too:

• Keep your site updated: Most compromises start with outdated plugins, themes, or core files. A patched site is less likely to be the one that gets hacked.
• Use correct file permissions: 755 for directories and 644 for files is standard. Never use 777, and consider 600 or 640 for wp-config.php.
• Use strong, unique passwords and 2FA on your hosting account, CMS, and email.
• Don't host unrelated sites in one account: If one site in an account is hacked, every other site in the same account is exposed, because isolation works between accounts, not within them. Use separate accounts for important sites where your plan allows.
• Remove old installations: Forgotten test sites are a common entry point.
• Keep off-site backups: If something does go wrong, you can restore quickly.
• Upgrade when you outgrow shared hosting: If your site handles payments, personal data, or significant traffic, a VPS or container-based managed host gives you stronger isolation.

Isolation Within Your Own Account

That point about multiple sites in one account deserves emphasis. Many people host a main site, a staging copy, an old blog, and a client's site all in the same cPanel account. Server isolation won't help here: all those sites run as the same user, so a vulnerability in any one of them gives access to all of them.

If you manage your own server, you can apply the same principle yourself by giving each site its own system user and PHP-FPM pool. A minimal pool definition looks like this:

[site-one]
user = siteone
group = siteone
listen = /run/php/php8.3-fpm-siteone.sock
listen.owner = www-data
listen.group = www-data
pm = ondemand
pm.max_children = 5
php_admin_value[open_basedir] = /home/siteone/:/tmp/

Each site then runs as its own user, and ordinary file permissions keep them apart.

---

FAQ: Server Isolation in Shared Hosting

---

Conclusion

Server isolation is the invisible wall between you and every other customer on a shared hosting server. When it's done well, using per-user PHP, filesystem virtualisation like CageFS, resource limits, symlink protection, and separate database users, a hacked site next door is someone else's problem, not yours. When it's missing, your security is only as strong as the weakest site on the server.

When choosing or reviewing a host, ask directly how they isolate accounts, and look for the practical signs covered above. Then do your part by keeping your own site updated, separating important sites into different accounts, and moving to a VPS or container-based hosting once your site's value justifies stronger walls.