What container isolation means on our Starter, Simple, and Business plans, how it differs from ordinary shared hosting, and how the pieces work together.
Most people don’t think about where their website lives. They care that it loads, that it stays up, and that it doesn’t suddenly get slow. The setup underneath still matters, because it decides whether a busy or broken neighbor can reach your site.
The approach we use is sometimes called container hosting. Here’s what container isolation means in practice, and how the parts fit together.
The old shared-hosting problem
Traditional shared hosting puts many websites on the same server. Resource limits exist, but they are often soft. When one site gets a traffic spike, a poorly written script, or a malware infection, the effects can spill over. A neighbor can use more than its share, and the only thing keeping sites apart may be file permissions.
You’ve probably felt this as a site that is fine most of the time and then suddenly slow for no reason you can see. The cause is often a neighbor on the same machine. That model worked for years when most sites were simple and traffic was lighter. It’s a poorer fit now that sites run more plugins, more dynamic pages, and more background tasks.
What a container changes
A container is a lightweight boundary around a website’s files and the PHP processes that run its code. On every Starter, Simple, and Business plan, each site runs inside its own container. It can see only its own files, runs its own PHP processes, and has hard limits on CPU, memory, and disk that match the plan.
Think of it as a private room with its own walls, its own power limit, and its own lock. The room is still inside the larger building (the server). The walls keep one site’s files and code from mixing with the others.
Because those limits are enforced by the operating system, a site that tries to use more than its share is held to its own caps. A busy neighbor is much less likely to slow your site. If malware appears in one site, it doesn’t have a simple path to the files or PHP processes of another site. The container is the main isolation layer for your site’s files and code.
Why this is better than ordinary shared hosting
You still get the convenience of shared hosting: a control panel, one-click installs for WordPress and Joomla, automatic SSL, and off-server backups. You don’t have to manage a server yourself. The difference is the boundary around each site, and the limits that go with it.
| Topic | Ordinary shared hosting | Container isolation |
|---|---|---|
| Performance | Limits are often soft. A neighbor’s spike or heavy script can slow your site. | Hard limits on CPU, memory, and disk match your plan. A busy neighbor is held to its own limits, so it is much less likely to slow your site. |
| Isolation | Accounts often share processes and rely on file permissions. | Each site’s PHP and files run in its own container. Other accounts cannot see those files. |
| Recovery | Backups and restores vary by host. | Backups, restores, and staging copies are handled per site from your control panel. Off-server backups run on one schedule, at least 48 hours apart, are kept 30 days, and include your databases. |
| Day-to-day management | A control panel, installs, and SSL, depending on the host. | Your control panel, one-click installs for WordPress and Joomla, automatic SSL, and off-server backups. You don’t run a server yourself. |
But what about CloudLinux?
Many shared hosts use CloudLinux, a commercial operating system designed for shared servers. CloudLinux and our containers aim at the same job: keeping one customer’s site from using another’s resources or reading another’s files. They do it differently.
CloudLinux typically sets limits and a private file area for each hosting account, and it offers an optional feature that can separate the websites inside one account.
The table above describes ordinary shared hosting in general, not CloudLinux.
We do not use CloudLinux on Starter, Simple, or Business plans. Each of those plans holds one website, and that website runs in its own container. The container has its own view of processes, files, and network, and hard limits on CPU, memory, processes, and disk. Because each plan is one site, your site’s limits and your plan’s limits are the same thing.
The web server and the database sit outside the containers and are shared on the server. The web server hands PHP work into the site’s container, and database access is limited by per-site users and permissions. The container limits apply to your site’s own code.
How the two approaches are built
This table describes how each is built, not which is better.
| CloudLinux, typically | Starter, Simple, and Business | |
|---|---|---|
| What it is | A commercial operating system designed for shared servers | Each site runs in its own container |
| How isolation is applied | Limits and a private file area for each hosting account. An optional feature can separate websites inside one account. | Each plan holds one website, and that website is its own container, with its own view of processes, files, and network, and limits on CPU, memory, processes, and disk. |
| Web server and database | Shared on the server | Shared on the server, outside the container. The container limits apply to the site’s own code. |
How the pieces fit together
The container is the unit for your site’s files and PHP. The web server and the database run on the same server, outside the container, and serve every site on that machine.
OpenLiteSpeed
Your site runs on OpenLiteSpeed, the open-source edition of LiteSpeed Web Server, with LSCache. OpenLiteSpeed receives each request and hands the PHP work to your site’s own container, where your code runs inside your site’s limits.
MariaDB
Your databases run on MariaDB on the same server as your site. Each site has its own database users and permissions, so other accounts cannot read or change your data, and a script using your site’s credentials cannot reach other sites’ databases.
PHP
PHP runs inside your site’s container. You choose the PHP version for your site in your control panel. Your PHP processes are limited by your plan’s CPU and memory, and they can’t see other sites’ files.
Security layers
Our servers run firewall and malware-scanning tools, and every site sits in its own container, which limits how far a problem can spread. Free SSL is issued and renewed automatically. Two-factor authentication is available for your hosting control panel login.
These pieces aren’t separate products you have to wire together. OpenLiteSpeed in front of your container handles requests. PHP runs your site’s code inside the container. MariaDB on the same server stores its data. Server-level security tools add another layer.
What you actually experience
- A busy neighbor is held to its own limits, so it is much less likely to slow your site.
- A problem in another account is far less likely to reach your files or your site’s code.
- You manage files, databases, SSL, backups, staging, and one-click installs for WordPress and Joomla from one control panel. Your control panel shows your disk and bandwidth use.
- Off-server backups run on one schedule, at least 48 hours apart, and are kept for 30 days. They include your databases. You can restore a backup yourself from your control panel.
- Free SSL is issued and renewed automatically.
- Support 24/7/365 from people who know the platform.
Off-server backups
On one schedule, at least 48 hours apart, kept 30 days.
- Off the serverCopies are stored away from the live site.
- 48 hours apartAt least two days between backup runs.
- Kept 30 daysIncludes your databases, not only files.
- RestoreFrom your control panel.
You don’t have to become a system administrator to use any of this. Every Starter, Simple, and Business plan hosts one site in its own container, on the same software, with limits that match the plan. You choose the plan size that matches the disk, RAM, and vCPU your site needs. Those plans use the same container setup and software; they differ in disk, RAM, vCPU, and staging copies.
A practical note
Container isolation doesn’t make a site immune to problems in its own code. An outdated plugin, a weak password, or a misconfigured form can still cause trouble inside the container. Keeping software current, using strong passwords, and turning on two-factor authentication still matter. What the container changes is the blast radius. A problem stays smaller, and the performance of other customers is better protected.
We have been hosting customers since 2008. In 2024 we moved our hosting to this container-based setup to improve isolation and give each site a clear share of resources, without asking customers to manage servers themselves. Before that move, our older shared servers used CloudLinux.
If you want to see the current plans and the resources that come with each, they’re listed plainly on the pricing page. If you have a site you’d like moved, free best-effort migration is included with a new account.
For more on LiteSpeed, see LiteSpeed hosting. For NVMe shared plans, see shared hosting.