On shared hosting, one compromised site can affect every other account on the server. Containers change that equation entirely. Here's why the architecture matters.
Traditional shared hosting puts hundreds or thousands of websites on the same server, running under the same operating system processes, accessing the same filesystem. The cost savings are real. The security implications are also real, and rarely explained clearly to customers.
When a site on a shared server gets compromised - through an unpatched plugin, a weak password, or a vulnerable theme - attackers don't just have access to that site. They frequently have access to everything accessible to that server's web process. That can mean reading configuration files from neighbouring accounts, injecting malicious code into other sites' output, or using the server as a launchpad for further attacks.
This isn't theoretical. Cross-account contamination on shared hosting is common enough that security researchers have a name for it: lateral movement. It's the same concept that makes hospital network segmentation important - if one system gets infected, you want it contained, not free to spread.
A Docker container is an isolated execution environment. It has its own filesystem, its own network stack, its own process tree. The host Linux kernel enforces these boundaries using namespaces and cgroups - kernel-level features, not application-level security.
When your WordPress site runs in its own container:
The container is still running on shared hardware, but the isolation is genuine. It's not a convention or a configuration choice - it's enforced by the kernel.
On many shared hosts, all accounts share a single database server. Each site gets its own database, but they're on the same MySQL instance, accessible via the same credentials system. A SQL injection vulnerability in one site's plugin could, in poorly configured environments, be leveraged to query data from other databases on the same instance.
Containerised hosting sidesteps this in two ways. First, each site has its own database credentials scoped to only that site's database - no other databases are accessible even with valid credentials. Second, the database connection happens inside the container's network namespace, inaccessible from outside.
This one is less obvious but genuinely important. Containers run with hard CPU and memory limits enforced by the kernel. This means a site that's been compromised and is being used to send spam, mine cryptocurrency, or run a DDoS - the classic outcomes of a hacked WordPress install - is throttled by those limits.
On shared hosting, a compromised account can consume as many resources as it can grab, often triggering account suspension for the legitimate owner while the attacker's campaign runs at full speed until the host notices. With container limits, the blast radius is contained: the attacker gets a capped resource envelope and can't materially impact the host system or other customers.
WordPress has a large attack surface. The core project is well-maintained, but the plugin ecosystem is enormous and varied in quality. A site running 15 plugins has 15 potential vulnerability sources, each potentially introducing a security issue into an environment that shared hosting doesn't isolate.
The right response to this isn't to avoid plugins - it's to host WordPress in an environment where the blast radius of a plugin vulnerability is contained. That's what containers provide. A compromised plugin in a containerised WordPress install is a problem for that one site. On shared hosting, it's potentially a problem for every other account on that server.
Most hosting providers won't proactively explain their isolation model. It's worth asking directly: "Is each account's PHP process isolated from other accounts?" and "If my site were compromised, would it affect other sites on the same server?"
On traditional shared hosting, an honest answer to both questions is "no" and "potentially yes." On containerised hosting, the answers flip.
At DownUnder WP, every WordPress site runs in its own Docker container with its own PHP-FPM process, its own database user with scoped permissions, and its own network namespace. The isolation isn't a feature we've bolted on - it's the fundamental architecture. It's why we can offer a genuinely secure environment without asking you to manage any of the security configuration yourself.
Australian WordPress hosting from $5/month
Your own containerised environment on Australian NVMe servers. Simple, fast, and genuinely cheap.