Why Salieno Core Runs PHP Apps in Namespaced Containers, Not suPHP

The problem with the old way#

For over a decade, the shared hosting industry leaned on a handful of process-isolation tricks to keep tenants from stepping on each other. suPHP was the most popular: it ran every PHP script as the owning user, spawning a new PHP process per request. It was simple to reason about — your files, your UID — but brutally slow. No opcode cache, no persistent workers, and a fork-per-request model that collapsed under any real traffic.

CloudLinux's CageFS was the next evolution. It layered a per-user filesystem view on top of the kernel, hiding other tenants' files and restricting access to system binaries. Combined with PHP Selector and mod_lsapi, it gave hosts a reasonable balance of isolation and performance. But CageFS is a commercial kernel module. It ties you to CloudLinux's release cycle, their pricing, and their specific kernel patches.

Salieno Core takes a different approach entirely: Linux user namespaces, mount namespaces, PID namespaces, and cgroups — the same primitives that power Docker and LXC — applied at the individual hosting-account level.

How it works, concretely#

When a shared hosting account is provisioned in Salieno Core, several things happen under the hood:

1. A dedicated Linux user is created with a UID that is only meaningful inside that account's namespace. The host kernel sees a high-numbered UID (e.g., 100001), but inside the container the account "sees" itself as UID 1000 — the conventional first user.

1. A mount namespace is created for the account. The account's public_html, its PHP sessions directory, its /tmp — all of these are bind-mounted into a private view. Other accounts' directories are simply invisible. There is no /home/otheruser to stumble into, even through symlinks or race conditions.

1. A PID namespace isolates process visibility. The account's PHP-FPM workers and any spawned CGI processes can only see their own process tree. They cannot signal, inspect, or even list processes belonging to other tenants or the host system.

1. cgroups (v2) enforce CPU and memory limits per account. This replaces the older ulimit and rlimit approach with hard, kernel-enforced ceilings. If one account's PHP script starts consuming 2 GB of RAM, the OOM killer targets that cgroup — not the entire PHP-FPM pool.

1. Network namespaces are optional but available for plans that need isolated networking (useful for accounts that run their own Redis or Node.js sidecars on non-standard ports without colliding with neighbors).

The result is that each shared hosting account runs in something that looks and behaves like a lightweight container, but it is not Docker. There is no container runtime daemon, no image layering, no orchestration overhead. It is raw kernel namespaces, provisioned and torn down by Salieno Core's account lifecycle hooks.

Why not just use Docker?#

Docker (and OCI containers generally) are designed for application deployment, not multi-tenant shared hosting. The impedance mismatch is significant:

• Density. A Docker container typically runs one service. A shared hosting account runs a web server, PHP, cron, SSH, FTP, and often a database. Modeling all of that inside a single container means either stuffing everything in (against container best practices) or running a pod of containers per account (which kills density on a box hosting 500+ sites).

• Filesystem semantics. Shared hosting users expect to upload files via SFTP and see them immediately in their PHP scripts. Docker's layered filesystems (overlay2, etc.) add complexity to this simple expectation. Salieno Core's bind-mount approach means the account's directory on disk is the account's directory in the namespace — no layers, no copy-on-write surprises.

• Resource overhead. A minimal Docker container still carries the overhead of a container runtime, health checks, log drivers, and network bridge setup. Multiply that by hundreds of accounts per server and the cumulative cost is real. Raw namespaces avoid all of that.

• Familiarity. Hosting resellers and their customers expect chmod, chown, .htaccess, and php.ini to work as they always have. Namespaces preserve the traditional Unix hosting model while adding a security boundary that suPHP never had.

Performance implications#

The namespace-based isolation has a measurable performance benefit over suPHP and even over CageFS in certain workloads:

• Opcode caching works. Because PHP-FPM runs as persistent workers inside the namespace (not forked per request like suPHP), OPcache is fully functional. In benchmarks on a 4-core VPS with 200 WordPress accounts, this alone reduced average page-generation time by 40-60% compared to a suPHP configuration.

• No kernel-module dependency. CageFS requires the lve kernel module and CloudLinux-specific patches. Salieno Core's namespace approach works on any mainline Linux kernel from 4.6 onward (when user namespaces became unprivileged by default). This means you can run it on Debian, Ubuntu, AlmaLinux, or even Arch if you're feeling adventurous.

• Lower syscall overhead. CageFS intercepts filesystem calls at the VFS layer to enforce its virtual filesystem view. Namespace mount isolation happens at a lower level — the kernel simply never presents the other mounts to the process. The difference is small per-call but adds up across high-traffic PHP workloads.

What it does not solve#

Namespace isolation is not a silver bullet. A few things to be honest about:

• Kernel exploits. If a namespace escape vulnerability exists in the kernel, all bets are off — just as they are with Docker, LXC, and CageFS. Keeping the kernel patched is still a non-negotiable operational requirement.

• Shared kernel. All accounts share the host kernel. A kernel-level resource exhaustion (e.g., a fork bomb that somehow escapes cgroup limits, or a kernel memory leak triggered by a specific syscall pattern) affects everyone. This is inherent to any container-based isolation model.

• Database isolation. Salieno Core namespaces isolate the filesystem and process tree, but shared MySQL/MariaDB instances are still shared. Per-account database user privileges and query resource limits (via max_user_connections and proxy tools like ProxySQL) are the defense layer there, and they operate independently of namespaces.

The practical takeaway#

For hosting resellers evaluating infrastructure choices, the question is not "Docker vs. namespaces" in the abstract. It is: what isolation model gives you the density, performance, and operational simplicity that shared hosting economics demand?

Salieno Core's namespace approach gives you container-grade isolation without container-grade complexity. Your customers get a familiar hosting environment. You get hard boundaries between accounts, kernel-enforced resource limits, and the ability to run PHP-FPM with full opcode caching — all without a commercial kernel module.

If you are currently running suPHP and losing sleep over performance, or running CageFS and losing sleep over vendor lock-in, the namespace model is worth a serious look. It is not a theoretical exercise; it is how the next generation of shared hosting platforms will isolate tenants, and it is available now.