Shared hosting explained

Hundreds of accounts on one operating system, separated by file permissions and a control panel. It is the cheapest way to put a normal website online, and the limits are real but mostly invisible until you hit them.

How the sharing actually works

A shared host runs one operating system on one machine and gives each customer a Unix account under it. Your files live in your home directory, your site runs as your user, and a control panel exposes a narrow, safe subset of the system: upload files, create databases and mailboxes, point domains, install a certificate.

Everything underneath that is the host's: the kernel, the web server, the PHP build, the MySQL daemon, the mail stack. You cannot install a system package, change the web server's configuration beyond what .htaccess allows, or run a process that outlives the request that started it.

That is the trade. You give up the lower half of the stack and in exchange somebody else patches it, monitors it and gets paged when it breaks.

What the limits are, in practice

The advertised numbers — storage, bandwidth, "unlimited" anything — are rarely what you run into first. The binding constraints are the ones in the fine print:

• Concurrent processes and entry processes. A cap on how many requests your account may execute at once. Exceed it and visitors get a 503 while the server is otherwise healthy.
• CPU seconds and I/O rate. Usually enforced per account per unit of time, and usually the thing a plugin-heavy CMS trips first.
• Inodes. A file count limit. Caches, mail and backups quietly consume it, and hitting it stops writes long before the disk is full.
• Database connections and query time. Shared MySQL instances kill slow queries to protect the neighbours.
• No background work. Cron is often throttled to a few runs an hour, and daemons are prohibited outright.

"Unlimited" plans are unlimited in the resources that are cheap and capped in the resources that are not. Read the acceptable-use policy, not the pricing page.

Noisy neighbours

Because the machine is shared, another account's bad afternoon is partly your afternoon. A site under a traffic spike, a runaway backup job or a compromised account consuming CPU all show up as latency on yours. Good hosts contain this with per-account limits — the same limits listed above, seen from the other side.

The security equivalent matters more. On a correctly configured host accounts cannot read each other's files; on a badly configured one, a world-readable config file with database credentials is a real exposure. You cannot audit this from the inside, which is the honest argument for moving up a tier once a site holds anything sensitive.

When shared hosting is the right answer

More often than hosting discussions admit. A brochure site, a blog, a small shop, a club, a portfolio — anything whose traffic is measured in hundreds or low thousands of visits a day and whose stack is off-the-shelf PHP — runs fine, and runs fine without anybody learning to administer a server.

The decision is not really about traffic. It is about whether you need to install things. The moment your project wants a specific runtime version, a background worker, a queue, a cache daemon, a non-standard database or a service listening on its own port, shared hosting stops being cheap and starts being a wall.

Signs you have outgrown it

• Intermittent 503s or "resource limit reached" pages during normal traffic
• The host emailing you about CPU use
• Needing a runtime or extension the panel does not offer
• Wanting a staging copy, a deploy pipeline or version control on the server
• A background job that has to run more often than cron allows
• Anything that must hold data you would be embarrassed to leak

The usual next step is a VPS, not a dedicated server — see how a VPS differs.