Shared hosting is a hosting model in which many customer accounts run on the same server and share its CPU, memory, disk, network connection and software stack, while each customer manages only its own websites, databases and mailboxes. The provider administers the operating system, web server and security, and customers work through a control panel such as cPanel, Plesk or DirectAdmin without root access.
Because the cost of one machine is divided among dozens to hundreds of accounts, shared hosting is the lowest-cost entry point to running a website. The trade-off is that performance, security and configuration freedom depend on the provider’s limits and on the behavior of neighboring accounts.
How shared hosting divides one server
On a shared hosting server, each customer receives a separate system user, home directory and set of virtual hosts. A single web server such as Apache, LiteSpeed or Nginx serves all domains, selecting the right site through the HTTP Host header and, for HTTPS, through Server Name Indication (SNI), which allows many certificates on one shared IP address.
Dynamic code runs under the customer’s own user account, typically through per-user PHP-FPM pools or LiteSpeed’s LSAPI, so one account cannot read another’s files through ordinary permissions. One MySQL or MariaDB server holds the databases of all accounts, separated by database users and privileges.
Modern platforms add kernel-level resource isolation. Technologies such as CloudLinux Lightweight Virtual Environments (LVE) and Linux cgroups cap what each account may consume, and a virtualized file system like CageFS hides other users and system files. Without these layers, a single runaway script could exhaust the entire machine.
Resource limits that define a shared hosting plan
The advertised disk space and bandwidth rarely decide whether a site runs well; the per-account process and CPU limits do. The table lists the limits commonly enforced on shared hosting accounts, with typical ranges that vary by provider and plan.
| Limit | Typical range | What happens when reached |
|---|---|---|
| CPU (SPEED) | 100-200% of one core | Requests slow down through throttling |
| Physical memory | 512 MB-2 GB | Processes are killed, often with HTTP 500 or 503 |
| Entry processes | 20-50 | New requests receive HTTP 508 or 503 |
| Number of processes | 50-200 | New PHP, cron or SSH processes cannot start |
| I/O throughput | 2-20 MB/s | Disk operations are slowed |
| Inodes | 150,000-500,000 files | No new files, emails or cache entries can be created |
Entry processes count the requests an account is executing at the same moment, not daily visitors. A limit of 20 entry processes easily serves thousands of visitors per day if each page completes in a fraction of a second, but it fails quickly when slow database queries keep processes busy.
Plans marketed as “unlimited” are governed by an acceptable use or fair use policy, and in practice the CPU, memory and inode limits above set the real ceiling.
Shared hosting compared with other hosting models
Shared hosting sits at the bottom of a ladder of increasing isolation, control and cost. The comparison shows where it differs from the models customers usually move to next.
| Model | Isolation | Root access | Who administers the server |
|---|---|---|---|
| Shared hosting | Accounts on one operating system | No | Provider |
| VPS | Own virtual machine | Yes | Customer, unless managed |
| Managed hosting | Varies, often VPS or dedicated | Usually limited | Provider, with application tuning |
| Dedicated server | Whole physical machine | Yes | Customer or provider |
| Cloud instances | Virtual machine with elastic scaling | Yes | Customer |
The key distinction is the shared operating system kernel and software stack. On a VPS, each customer has its own kernel and can choose PHP versions, web server modules and firewall rules; on shared hosting, customers select only what the control panel exposes, such as the PHP version per domain.
When shared hosting fits and when it does not
Shared hosting suits workloads with modest, predictable traffic and standard software. The decision table maps typical situations to a recommendation.
| Situation | Recommendation | Reason |
|---|---|---|
| Brochure site or small blog | Shared hosting | Low load fits default limits |
| Small store with a few orders daily | Shared hosting with caching | Page cache keeps entry processes low |
| Traffic peaks from campaigns | VPS or managed hosting | Fixed limits cause errors at peaks |
| Custom daemons, Node.js or Docker | VPS or cloud | Long-running processes are not allowed |
| Strict compliance requirements | Dedicated or isolated environment | Shared kernel complicates audits |
A practical signal for moving on is repeated resource faults in the control panel’s usage statistics. When an account regularly hits its entry process or memory limit after caching and query optimization, the workload has outgrown the shared model.
Risks and common misconceptions
The main risks of shared hosting come from sharing infrastructure with unknown neighbors. Several of them are not visible in plan descriptions.
- Noisy neighbors: heavy disk or database load from another account can slow every site, even when per-account limits are in place.
- Shared IP reputation: if another account sends spam, the shared mail IP address can land on blocklists and hurt email delivery.
- Weaker isolation without hardening: on servers lacking per-user execution and file system isolation, one compromised site can expose others.
- Backups are not guaranteed: provider backups are often best-effort, so customers should keep independent copies.
- No server-level tuning: settings such as kernel parameters, web server modules or database configuration remain under provider control.
Put simply
Shared hosting is like renting a room in a large shared apartment. The landlord looks after the building, heating and repairs, and each tenant has a private room with a lock, but everyone shares the same kitchen and hot water.
It is cheap and convenient for most small websites. If a neighbor uses too much of the shared resources, everyone may notice, and when a website grows busy, it is time to move to a place of its own.
In practice
A local accounting office runs a six-page website and a contact form on a shared hosting plan with 1 CPU core, 1 GB of memory and 25 entry processes. The site receives about 300 visits per day, peak load stays far below the limits and the provider handles updates of the operating system and web server.
Two years later, the office adds an online booking system and a tax-season newsletter campaign. On campaign mornings, the control panel shows dozens of entry process faults and visitors see HTTP 508 errors. The office enables page caching, which reduces faults but does not eliminate them during peaks.
The office finally moves to a managed VPS with 4 cores and 8 GB of memory. The booking system now handles campaign peaks without resource errors, at a monthly cost several times higher than the shared plan.