On a traditional shared hosting server, hundreds of websites live side by side in one big environment. They share a web server, often share PHP worker pools, and compete for the same CPU and memory. It works, until one site gets hacked, goes viral, or runs a badly written plugin. Then every other site on the box feels it.
Container-per-site hosting fixes this by giving each website its own isolated environment. Unicorn Panel does this by default for every site, on every plan, including the free one. This article explains what container-per-site hosting is, why it matters, and how it works in practice.
What is container-per-site hosting?
Container-per-site hosting means each website runs inside its own container: a lightweight, isolated environment with its own processes, its own user, its own network ports and its own resource limits. Containers share the host's kernel, so they are far lighter than a virtual machine per site, but each one sees only its own files and processes.
In Unicorn Panel, every site gets:
- Its own container, managed by Podman on an Alpine Linux host
- Its own Linux user, so file ownership never crosses between tenants
- Its own ports, so sites do not compete for sockets
- Its own PHP-FPM pool, with no shared pool one site could read another through
- Its own limits on CPU, memory, disk and processes
The security page sums it up: nothing is shared between tenants.
The problems with shared environments
The noisy neighbor
When sites share resources, one heavy site can slow everyone. A traffic spike, a runaway cron job or a plugin stuck in a loop can use up CPU or memory that other customers are paying for. The usual response is a support ticket from the customers who did nothing wrong.
With per-site limits, a busy site hits its own ceiling and slows down on its own. Its neighbors keep running normally.
Cross-site compromise
Most website compromises start with outdated CMS software or a vulnerable plugin. On a shared environment, an attacker who gets code execution in one site may be able to read other sites' files, especially where permissions are loose or a PHP pool is shared.
Per-site containers turn a compromise into a contained problem. The attacker lands inside one container, running as one user, with access only to that site's files. File access in Unicorn Panel is jailed per tenant, including bulk moves and copies made through the panel.
One configuration for everyone
Shared environments tend to force one PHP version, one set of extensions and one web server configuration on every site. That makes legacy sites a problem and modern sites a compromise.
Containers let each site carry its own runtime. In Unicorn Panel the PHP version and web engine are both chosen per site, and both can be changed later. We cover the PHP side in running PHP 5.6 to 8.5 side by side.
Containers vs other isolation methods
| Approach | Isolation strength | Overhead | Per-site runtime choice |
|---|---|---|---|
| Shared environment, shared PHP pool | Low | Lowest | No |
| Per-account PHP-FPM pools | Medium | Low | Limited |
| Per-account cgroups limits | Medium, resources only | Low | Limited |
| Container per site | High: processes, users, ports, files, limits | Low | Yes |
| Virtual machine per site | Highest | High | Yes |
Containers hit a sweet spot for hosting: strong isolation without the memory cost of a full virtual machine for every website. That is why a single modest server can still run many isolated sites.
Why isolation should not be an add-on
On several established panels, stronger per-site isolation arrives through an extra product or a higher edition. Unicorn Panel's comparison page, checked in September 2026, notes that cPanel needs paid CloudLinux for this, while Plesk, DirectAdmin and Virtualmin rely on per-account cgroups, in some cases only on higher editions.
Unicorn's view is simple: isolation is a baseline, not a feature to upsell. Every site on the free tier gets exactly the same container model as a site on a 50-server enterprise fleet.
How it works in Unicorn Panel
When you create a site in the website wizard, you choose which server it lands on. The panel then builds everything on that host: the container, the user, the files, the web server configuration and a Let's Encrypt certificate. Each step reports when it has actually finished rather than when a progress spinner feels done.
From then on, the site lives in its own world:
- Resource limits are set per site so one busy site cannot starve its neighbors.
- The browser terminal drops the site owner into their own container, where they can restart their services or install extra packages without touching the host.
- Container packages can be toggled on in Settings to give web applications additional software by default.
- Logs for the web server and PHP stream live from that site's container.
- Redis or Memcached can run alongside the site, scoped to it.
For the operator, the unicorn CLI manages containers directly. unicorn podman list-containers shows every tenant container and its status, and unicorn podman recreate-container <UID> rebuilds one site's container from the panel's stored settings, including mounts, limits and image.
Isolation across a whole fleet
Container-per-site becomes even more powerful when you run several servers. Because every site is a self-contained unit, it can live on any host in your fleet. You choose where each site runs, spread heavy sites across servers, and keep critical customers on quieter machines. Hosts coming back from a reboot bring their tenant containers up patiently, retrying slow starters rather than leaving sites down. Read how the fleet model works in our multi-server pillar guide.
Why Podman and Alpine
Unicorn Panel uses Podman for containers on Alpine Linux hosts. Alpine keeps the host small and fast, so more memory goes to tenant containers. Podman runs containers without a single long-lived central daemon owning every container, which fits a design where each site is its own independent unit. More on the Alpine side in a free web hosting control panel built for Alpine Linux.
Isolation is the first layer, not the only one
Containers limit the damage when something goes wrong. Unicorn Panel adds more layers around them: Unicorn Shield bans brute-force and malicious traffic at the firewall, fleet-wide malware scanning covers every host, and sign-in supports passkeys and 2FA that also protects password resets. Our security checklist goes through each layer.
Frequently asked questions
Does container-per-site hosting use much more memory? Much less than a virtual machine per site. Containers share the host kernel, so the overhead per site is small.
Can customers break out of their container? Containers are a strong isolation boundary, and Unicorn Panel adds per-tenant users, jailed file access and no shared PHP pool. As with any system, keep the host and roles updated.
Is per-site isolation available on the free plan? Yes. Every site on every plan gets its own container.
Can I still use WordPress and other PHP apps normally? Yes. Sites behave like normal web hosting, with a WordPress toolkit built in.
Give every site its own space
Shared environments made sense when servers were scarce. Today, container-per-site hosting gives you stronger security, fairer resource sharing and per-site flexibility at very little cost. Unicorn Panel makes it the default, free for your first two servers.
wget -qO- https://unicornpanel.com/install | shOr try the live demo and see isolated sites in action.