Shared hosting means your website runs on a server alongside other websites. The server’s CPU, RAM, storage, and bandwidth are shared between all accounts. Each account gets a slice of the total resources, managed by software that keeps one site from consuming everything.
It is the most common and most affordable type of web hosting. The vast majority of websites on the internet run on shared hosting of some kind. If you have ever signed up for hosting from a provider and got a control panel login, you were almost certainly on a shared server.
The concept is straightforward. The implementation and the quality of that implementation vary enormously between providers.
How traditional shared hosting works#
A traditional shared hosting server runs a stack that typically looks like this:
- Operating system: Linux (CentOS, AlmaLinux, CloudLinux, or Rocky Linux)
- Control panel: cPanel, Plesk, or DirectAdmin
- Web server: Apache, Nginx, or LiteSpeed
- PHP handler: PHP-FPM or mod_lsapi (runs PHP code for each account)
- Database: MySQL or MariaDB (shared instance, separate databases per account)
- Isolation: CloudLinux CageFS (filesystem-level isolation between accounts)
- Resource limits: CloudLinux LVE (enforces CPU, RAM, I/O limits per account)
When a visitor loads your website, the request flows through the web server, which identifies which account the domain belongs to, executes your PHP code under your user account, queries the shared MySQL instance for your database, and returns the response. All of this happens on one machine alongside hundreds of other accounts doing the same thing simultaneously.
The control panel
cPanel is the de facto standard for traditional shared hosting. It gives each account a web interface for managing domains, email, databases, files, and basic server settings. The hosting provider installs cPanel on the server, and each customer gets their own cPanel login scoped to their account.
cPanel handles the complexity of multi-tenant server management. When you add a domain in cPanel, it creates the Apache virtual host, the directory structure, the DNS zone, and the SSL certificate. When you create a database, it creates the MySQL database and user with permissions scoped to that database only.
The provider manages the server. You manage your account through cPanel. That division of responsibility is the core value proposition of shared hosting.
How isolation works
On a raw Linux server, all users can see each other’s processes and potentially read each other’s files if permissions are misconfigured. Shared hosting needs isolation to prevent this.
CloudLinux’s CageFS creates a virtualized filesystem for each user. When your PHP code runs, it sees a restricted view of the server. It cannot access other users’ home directories, cannot read sensitive system files, and cannot see system binaries it should not have access to. The underlying mechanism uses bind mounts and a skeleton directory structure that creates a per-user view of the filesystem.
CloudLinux’s LVE (Lightweight Virtual Environment) adds resource limits using kernel cgroups. Each account gets a CPU limit, a memory limit, I/O bandwidth limits, and process count limits. When your site exceeds its allocation, the limits enforce a ceiling. Your site slows down or returns errors, but other sites on the server are protected from your resource consumption.
This combination – CageFS for filesystem isolation and LVE for resource control – is what makes traditional shared hosting work. Without it, one compromised site could read every other site’s database credentials, and one traffic spike could take down the entire server.
How resources are shared
A typical shared hosting server might have 32 CPU cores, 128 GB of RAM, and NVMe storage. The provider puts 200-500 accounts on that server, with each account allocated a fraction of the total resources through LVE limits.
The math works because most websites are idle most of the time. A small business website that gets 500 visitors a day spends the vast majority of its time doing nothing. The server handles the aggregate load of all accounts, and the probability of all accounts being busy simultaneously is low.
This is called overprovisioning. The total resources allocated to all accounts on paper exceed the physical capacity of the server. It works as long as the provider manages the ratio carefully. Put too many accounts on a server, and performance degrades for everyone during peak hours.
The limitations of traditional shared hosting#
The noisy neighbor problem
When one account on the server consumes a disproportionate share of resources, other accounts feel it. LVE limits help, but they are not instant. A sudden traffic spike or a runaway PHP process consumes resources before the limits kick in. During that window, other accounts experience slower response times.
The noisy neighbor problem is inherent to any shared environment, but how well the hosting provider manages it – server density, resource limits, monitoring, and how quickly they intervene – determines how much it affects you.
Shared PHP processes
On traditional shared hosting, PHP-FPM or mod_lsapi manages a pool of PHP workers shared across the server. When a request comes in for your site, it gets assigned an available worker from the pool. If all workers are busy serving other accounts, your request waits in a queue.
During peak times, this queuing creates latency even when your own site is not under heavy load. You are waiting because other accounts on the server are keeping the workers busy. The total PHP worker count is a hard limit that affects every account.
Shared IP reputation
All accounts on a traditional shared server typically share one or a small number of IP addresses. If one account sends spam, hosts malware, or gets flagged by a security blocklist, the IP address gets penalized. That penalty affects every account sharing the IP.
Email deliverability is particularly sensitive to this. If the server’s IP is on an email blocklist because another account was sending spam, your legitimate emails may bounce or land in spam folders. This is one of the strongest arguments for using a dedicated email provider rather than relying on hosting-based email.
Shared database instance
All accounts share the same MySQL or MariaDB instance. Database performance is one of the hardest things to isolate on a shared server. Connection limits, buffer pool pressure, and long-running queries all affect every account on the same MySQL instance.
Limited configuration control
On shared hosting, you do not have root access. You cannot change the server’s Nginx or Apache configuration beyond what the control panel exposes. You cannot install system packages. You cannot change PHP settings that are locked by the provider. You cannot tune MySQL for your specific workload.
This is a feature, not a bug – it prevents one account from breaking the server for everyone else. But it means you cannot optimize beyond what the provider’s default configuration allows.
Security boundaries
CageFS provides filesystem isolation but not process isolation. Your account’s PHP processes run on the host’s shared kernel, in the host’s process namespace, using the host’s network stack. If a kernel vulnerability allows privilege escalation, every account on the server is potentially exposed.
This is the fundamental security limitation of CageFS: filesystem isolation without process, network, or kernel boundary separation. For a detailed technical comparison of CageFS versus container-based isolation, see how Hostney isolates websites with containers.
Who shared hosting is right for#
Despite its limitations, shared hosting is the right choice for many websites:
Small business websites. A brochure site, a portfolio, a local business site that gets a few hundred visitors a day does not need dedicated resources. Shared hosting handles this workload easily and affordably.
Personal blogs. A WordPress blog with moderate traffic does not need container isolation or dedicated CPU cores. Shared hosting runs it fine.
Development and staging sites. Sites that are not customer-facing and do not need guaranteed performance are perfect for shared hosting.
Budget-constrained projects. When cost is the primary concern and the site is not mission-critical, shared hosting at a few dollars per month makes sense.
Sites with predictable, low traffic. If your traffic pattern is steady and modest, the resource sharing inherent to shared hosting rarely becomes a problem.
Shared hosting is not a good fit for:
WooCommerce stores or other e-commerce sites where a slow checkout means lost sales. The noisy neighbor problem and shared PHP workers can cause latency at the worst possible time. Managed WordPress hosting with container isolation and dedicated PHP workers is a better fit.
High-traffic sites. Once your site consistently serves thousands of concurrent visitors, you need dedicated resources, not shared ones.
Sites handling sensitive data. If you need strong isolation guarantees for compliance or security requirements, CageFS-level isolation may not be sufficient.
Applications that need custom server configuration. If you need specific PHP extensions, custom MySQL tuning, or Nginx configuration changes, shared hosting’s locked-down environment will frustrate you.
What modern shared hosting looks like#
The traditional cPanel + CloudLinux model has been the standard for over a decade. It works, and it is still what most providers offer. But the technology has moved forward.
Modern shared hosting uses containers instead of CageFS for isolation. Each account gets its own container with its own process namespace, mount namespace, and resource limits. The underlying concept is the same – multiple accounts on one server, sharing hardware – but the isolation boundaries are fundamentally stronger.
Container-based shared hosting
Instead of CageFS creating a filtered view of the host filesystem, each account runs inside its own container. The container has its own process table (cannot see other accounts’ processes), its own filesystem (a container image, not a filtered view of the host), and its own resource allocation enforced by kernel cgroups.
The practical difference for the site owner:
| Traditional (CageFS) | Container-based | |
|---|---|---|
| Process isolation | Shared process table | Separate namespace per account |
| Filesystem | Filtered view of host | Container image + mounted home directory |
| PHP versions | Shared binaries on host | Per-container PHP installation |
| Resource enforcement | LVE (proprietary kernel module) | cgroups (standard kernel) |
| Kernel dependency | CloudLinux modified kernel | Any standard Linux kernel |
| Escape blast radius | Entire server | Single container |
Container-based shared hosting is still shared hosting. Multiple accounts still share one physical server. The hardware costs are still distributed across accounts, keeping prices accessible. But the isolation between accounts is closer to what a VPS provides than what traditional shared hosting offers.
The “shared but isolated” model
This is where the hosting landscape is heading. The economics of shared hosting – affordable because costs are distributed – combined with the isolation of containers. You get the pricing benefit of sharing a server without the security and performance drawbacks of sharing a runtime environment.
The server still has a finite amount of CPU, RAM, and storage. Overprovisioning still happens. But the blast radius of any problem – a compromised site, a resource spike, a misconfigured plugin – is contained to the individual account’s container rather than affecting the entire server.
Shared hosting vs VPS vs managed hosting#
These three models represent different tradeoffs between cost, control, and management burden.
Shared hosting is the most affordable. You share a server, you get a control panel, the provider manages everything. You have limited configuration control but zero server administration responsibility.
A VPS (Virtual Private Server) gives you your own virtual machine with root access. You control the entire stack – operating system, web server, PHP, database, firewall, everything. The isolation is strong (hypervisor-level), and resources are dedicated. But you are responsible for all server administration: security patches, PHP upgrades, database tuning, backups, firewall rules, SSL certificates, and everything else that keeps a server running and secure. An unmanaged VPS is not “better” than shared hosting if you do not have the skills or time to manage it.
Managed cloud hosting combines the isolation and dedicated resources of a VPS with the managed experience of shared hosting. The provider handles the server stack, and you manage your website. It costs more than basic shared hosting but less than a managed VPS, and it eliminates the server administration burden.
For a deeper comparison of these models and what to look for when evaluating hosting, see cloud WordPress hosting explained.
What to look for in a shared hosting provider#
If shared hosting is the right fit for your site, these are the things that differentiate providers. For a comprehensive guide to evaluating any WordPress host – including what marketing claims to ignore and how to test before committing – see how to choose WordPress hosting: what actually matters.
Server density
How many accounts does the provider put on each server? This is rarely advertised, but it directly affects performance. A provider with 200 accounts per server will deliver better performance than one with 1,000 accounts on identical hardware. You can get a rough sense by checking if the provider specifies resource allocations per account. If they do, multiply by the server’s likely hardware specs and see if the math is reasonable.
Isolation model
Is it CageFS, containers, or something else? This affects your security posture. CageFS is the industry standard and adequate for most use cases. Containers provide stronger isolation. Ask if you are not sure.
Resource limits
Are resource allocations specified per account, or is it “unlimited everything”? Specified limits mean the provider has thought about density and allocation. “Unlimited” means they are overprovisioning aggressively and hoping you do not notice.
Storage type
NVMe storage is meaningfully faster than SATA SSD for WordPress workloads because WordPress generates heavy random I/O patterns. The difference shows up in uncached page loads, database-heavy operations, and WooCommerce stores.
Caching stack
Server-level page caching (Nginx or LiteSpeed cache) dramatically improves WordPress performance. Object caching (Memcached or Redis) reduces database load. OPcache eliminates repeated PHP compilation. A provider with all three layers will outperform one with faster hardware but no caching.
Security
Does the provider run a firewall? Bot detection? Malware scanning? A web application firewall? WordPress is constantly targeted by automated attacks. The hosting environment should provide security layers beyond what WordPress plugins offer. See ModSecurity for how a server-level WAF works.
Backup frequency and process
Daily backups stored on separate infrastructure with at least 14 days of retention is a reasonable baseline. Understand how restoration works before you need it.
Shared hosting on Hostney#
Hostney is technically shared hosting – multiple accounts run on each server, and the cost of hardware is distributed across those accounts. But the implementation uses container isolation instead of CageFS, which changes the practical experience significantly.
Each account runs in its own Podman container with a separate process namespace, mount namespace, and cgroup-enforced resource limits. PHP runs inside the container with the specific version and extensions configured for that site. There is no shared process table, no shared PHP worker pool, no shared filesystem view. Each account operates as if it is on its own server.
Resources are specified per plan – CPU cores, RAM, I/O bandwidth, and IOPS – and enforced at the kernel level. These are not soft limits. When another account on the same server spikes, your resources are unaffected.
The security stack includes bot detection at the edge, ModSecurity with the OWARC Core Rule Set on every request, real-time malware detection with automatic quarantining, and SELinux in enforcing mode on all servers. Container isolation means a compromised site cannot pivot to other accounts – the blast radius is one container, not the server.
This is what shared hosting should be. The economics of shared hosting – affordable because costs are distributed – with isolation and security that eliminates the traditional drawbacks. You get a control panel, managed infrastructure, and support without needing to administer a server. The difference is under the hood.
Explore the hosting plans, read about the technology behind the platform, or see managed WordPress hosting for WordPress-specific details and pricing for a full comparison.