What Is Hosting Isolation? A Technical Guide to Securing Shared Servers (2026)

TL;DR

Hosting isolation refers to the techniques used to separate user accounts on shared servers, preventing cross-account attacks and resource abuse. Modern isolation combines multiple layers: cgroup v2 resource limits, Linux namespaces, SSH chroot jails, per-user PHP-FPM pools, and Unix permission separation. This guide explains each layer, how they work together, and which hosting panels implement them.

Why Hosting Isolation Matters

Shared hosting means multiple users on one server. Without proper isolation:

• Resource abuse — One user's traffic spike degrades everyone's performance
• Cross-account attacks — A compromised PHP script can read other users' files
• Process visibility — Users can see each other's running processes
• Privilege escalation — Poorly configured permissions allow lateral movement
• Fork bombs — A single user can exhaust all server processes

Hosting isolation addresses each of these risks through layered security controls.

The 5 Layers of Modern Hosting Isolation

Layer 1: Cgroup v2 Resource Isolation

What it does: Enforces hard limits on CPU, memory, I/O, and process count per user at the kernel level.

How it works: Each user gets a dedicated cgroup slice:

/sys/fs/cgroup/panelica.slice/panelica-user.slice/panelica-user-{username}.slice/
├── cpu.max        → CPU time limit (e.g., 200000 100000 = 2 cores)
├── memory.max     → Hard memory ceiling (e.g., 2GB)
├── io.max         → Disk I/O bandwidth/IOPS limits
└── pids.max       → Maximum process count (prevents fork bombs)

Key benefit: When a user exceeds their memory limit, only their processes are OOM-killed — not the entire server.

Layer 2: Linux Namespace Isolation

What it does: Gives each user an isolated view of system resources — processes, mounts, and network.

Key namespaces for hosting:

• PID namespace — Users see only their own processes (ps aux shows nothing from other accounts)
• Mount namespace — Isolated filesystem view per user
• User namespace — UID/GID mapping for additional separation

Key benefit: Even if an attacker gains shell access, they cannot enumerate other users' processes or access system mounts.

Layer 3: SSH Chroot Jails

What it does: Confines SSH/SFTP users to their home directory tree.

Two common modes:

• SFTP-only (jailed) — File transfer only, no shell access — ideal for web developers uploading files
• Full bash chroot — Shell access within a restricted directory tree — for users who need command-line tools

Key benefit: Users cannot cd / or navigate to /etc/passwd, /home/otheruser/, or any system directory.

Layer 4: Per-User Per-Version PHP-FPM Pools

What it does: Each user gets dedicated PHP-FPM worker processes with individual security configurations.

Configuration per pool:

• open_basedir — Restricts filesystem access to the user's directories only
• disable_functions — Blocks dangerous PHP functions (exec, system, passthru, etc.)
• memory_limit — Per-pool memory ceiling
• max_children — Individual process pool size

Per-version capability: Users can run PHP 8.1, 8.2, 8.3, or 8.4 simultaneously for different domains, each with isolated pools.

Key benefit: A PHP vulnerability in one user's application cannot affect other users' PHP processes.

Layer 5: Unix Permission Separation

What it does: Strict file ownership and permission enforcement at the OS level.

Implementation:

• Unique UID/GID per hosting account
• Home directories set to 700 (owner-only access)
• Web files owned by the user, read by web server group
• Temporary files isolated per user
• No shared group memberships between users

Key benefit: The foundational layer — even if all other isolation fails, Unix permissions prevent direct file access between accounts.

How the Layers Work Together

Consider an attack scenario on a shared server:

Each layer provides defense in depth. Bypassing one layer still leaves 4 others in place.

Isolation in Current Hosting Panels (2026)

*cPanel reaches 3-4 layers with CloudLinux (separate license required)

Implementing Isolation: DIY vs Panel

DIY Approach

You can implement isolation manually on any Linux server:

1. Enable cgroup v2 unified hierarchy
2. Create systemd slices per user
3. Configure namespace isolation
4. Set up OpenSSH chroot
5. Create PHP-FPM pool per user
6. Enforce strict Unix permissions

Pros: Full control, no panel dependency

Cons: Complex setup, manual maintenance, no automation, no UI for adjustments

Panel-Based Approach

Hosting panels that support isolation automate the entire process. When a user account is created, the panel automatically:

• Creates cgroup slices with plan-based limits
• Sets up namespace isolation
• Configures chroot jails
• Generates PHP-FPM pool configuration
• Enforces file permissions

Panelica, for example, automates all 5 layers as part of its user provisioning process.

Real-World Scenarios

Scenario 1: Noisy Neighbor

Problem: User A runs a misconfigured WordPress cron that consumes 100% CPU.

Without isolation: All sites on the server slow to a crawl.

With cgroup v2: User A hits their cpu.max limit. Their site slows down, but all other users maintain full performance.

Scenario 2: Cross-Account PHP Attack

Problem: User B's outdated plugin has an RCE vulnerability. An attacker gets PHP code execution.

Without isolation: Attacker reads /home/userC/public_html/wp-config.php and steals database credentials.

With 5-layer isolation:

• PHP open_basedir blocks access to other users' directories (Layer 4)
• Namespace isolation hides other users' processes (Layer 2)
• Unix permissions deny file read access (Layer 5)
• Chroot confines the attacker to User B's directory (Layer 3)

Scenario 3: Resource-Based DoS

Problem: Attacker sends massive traffic to User D's site.

Without isolation: Server runs out of memory, OOM killer randomly terminates processes across all users.

With cgroup v2: User D's cgroup hits memory.max. Only User D's processes are killed. Server remains stable.

FAQ

What is hosting isolation?

Hosting isolation refers to the security techniques used to separate user accounts on shared servers. It prevents one user from accessing another user's files, consuming their resources, or seeing their processes. Modern isolation uses multiple layers including cgroup v2, Linux namespaces, chroot jails, PHP-FPM pools, and Unix permissions.

Why do hosting providers need isolation?

Without isolation, shared hosting is fundamentally insecure. One compromised account can potentially access all other accounts on the same server. Isolation prevents cross-account attacks, resource abuse, and the "noisy neighbor" problem where one user's behavior degrades performance for everyone else.

What is the difference between cgroup v1 and cgroup v2?

Cgroup v2 uses a unified hierarchy (single tree), provides accurate memory accounting including kernel memory, properly handles buffered I/O limits, supports pressure stall information (PSI) metrics, and has deterministic per-cgroup OOM handling. Cgroup v1 had multiple hierarchies and broken I/O control.

Which hosting panels support cgroup v2 isolation?

As of 2026, Panelica provides native cgroup v2 isolation as part of its core architecture. cPanel can achieve similar isolation through CloudLinux (a separate third-party product). Most other panels do not offer cgroup-level isolation without additional OS licensing.

Is hosting isolation the same as containerization?

Hosting isolation uses the same underlying Linux kernel features (cgroups, namespaces) as container runtimes like Docker. However, hosting isolation is applied at the user account level rather than the application level, providing a more traditional hosting workflow with container-grade security controls.

Does isolation affect server performance?

Cgroup v2 and namespace isolation operate at the kernel level with negligible overhead. They use the same mechanisms that Docker and Kubernetes rely on for production workloads. The isolation is enforced by the Linux scheduler and memory manager, not by a separate monitoring process.

Can isolation prevent all attacks?

No security system is 100% immune. However, a 5-layer isolation architecture provides defense in depth — bypassing one layer still leaves multiple others in place. The combination of cgroup v2, namespaces, chroot, PHP-FPM isolation, and Unix permissions makes cross-account attacks significantly more difficult than on non-isolated shared hosting.

Understanding hosting isolation is essential for any hosting provider operating shared servers. As security threats evolve, multi-layer isolation using cgroup v2, namespaces, and per-user PHP-FPM pools is becoming the expected standard for modern hosting infrastructure.