Traditional shared hosting puts every customer's website on the same operating system, sharing the same PHP installation, the same Apache process, and the same filesystem. This was an acceptable trade-off in 2005 when the alternative was dedicated servers. In 2026, it's an architectural choice that creates unnecessary security risk, performance interference, and operational constraints.
Container-per-domain isolation is the alternative. Each domain runs in its own container — its own runtime environment, its own resource limits, its own filesystem. This article explains what that means in practice and why it matters for hosting providers and their customers.
What "Shared" Actually Means on Traditional Hosting
On a standard cPanel or DirectAdmin server, the isolation between accounts is minimal:
- All sites run under the same OS kernel
- PHP is a system package — one version serves all accounts (unless you use CloudLinux)
- Apache or nginx serves all domains from a single process
- A runaway script on one account can consume CPU and memory that affects all other accounts on the server
- A PHP vulnerability that affects one account can potentially be exploited to reach others
CloudLinux partially addresses this through CageFS, which creates per-user virtual filesystems. But it's a layer added on top of an architecture that wasn't designed for isolation — and it costs extra.
What Container Isolation Actually Does
When each domain runs in its own container, the isolation is structural rather than bolted on:
Filesystem Isolation
Each domain's files live on a dedicated PersistentVolume. The container can only see its own storage. A compromised site cannot read files from another domain — not because of access control rules, but because those files simply don't exist in that container's filesystem view.
Process Isolation
Each domain's PHP-FPM (or Python, or Node.js) process runs inside its own container. A PHP process that crashes or goes into an infinite loop affects only that container. Other domains on the same cluster continue running normally. There is no shared process space to corrupt.
Resource Isolation
Kubernetes enforces CPU and memory limits per container. If a domain is allocated 500m CPU and 512MB memory, it cannot consume more than that — regardless of how much traffic it receives. The "noisy neighbor" problem that plagues shared hosting doesn't exist in this model.
Runtime Isolation
This is where container-per-domain diverges most sharply from traditional shared hosting. On a LAMP server, upgrading PHP from 8.1 to 8.2 affects every site on the server simultaneously. Testing the upgrade requires careful coordination across all accounts.
With containers, each domain specifies its own runtime image. Site A runs PHP 8.0. Site B runs PHP 8.3. Site C runs Python 3.12. They coexist on the same cluster nodes without any interaction. Updating one domain's PHP version is a container image swap that takes seconds and affects nothing else.
This runtime isolation extends beyond PHP. Any language or framework that ships as a Docker image can become a hosting workload type. Ruby on Rails, Go, Java Spring Boot, .NET — each runs in its own isolated container, completely independent from every other domain on the cluster.
What This Means for Security
The security improvements from container isolation are significant:
- Lateral movement is structurally prevented. A compromised site cannot traverse to other sites via the filesystem because they don't share one.
- Credential scope is limited. Database credentials, SFTP keys, and email passwords for each domain are stored in Kubernetes Secrets scoped to that domain's namespace. A leaked credential for one site doesn't expose others.
- Network policies restrict traffic. Kubernetes network policies can prevent direct pod-to-pod communication between domains, so even a container escape can't reach neighboring workloads.
- Container images are immutable. The runtime environment for a domain is defined by its container image — a readonly artifact. Malicious code that modifies runtime files doesn't persist across container restarts.
What This Means for Your Hosting Business
Beyond the technical benefits, container isolation has practical business implications:
You can offer runtime choice as a selling point. "We support PHP 8.3, Python 3.12, and Node.js 22 — your choice per site" is a differentiator. Traditional hosting providers can't easily offer this.
Incidents are contained. When a customer's site gets hacked (and eventually, one will), the blast radius is limited to that container. You're not scrambling to audit 300 other accounts on the same server.
Resource guarantees are real. You can sell resource-allocated hosting plans and actually deliver on them. A customer paying for 1 CPU core and 1GB memory gets that, not "best effort sharing."
Upgrades are per-domain, not per-server. Moving a customer from PHP 8.1 to 8.3 is a configuration change on their domain, not a server-wide operation that requires testing all other accounts.
KubePanel implements container-per-domain isolation natively — every domain provisioned through the panel gets its own namespace, PVC, Deployment, and Secrets. There's no additional configuration required and no add-on cost. It's the default architecture.
Explore the security features or the multi-workload support to see how this plays out in practice.