Traditional WordPress hosting puts multiple sites on one server. They share PHP, they share file system access, and often they share a database server. This is fine until it isn't — and when it isn't, it's a serious problem.
NoDevZone provisions every WordPress site in its own Docker container. This post explains what that means in practice and why it matters for agencies managing multiple client sites.
The shared hosting problem
On a typical shared hosting plan or even a basic VPS with multiple WordPress installs:
Resource contention: one site getting a traffic spike slows down every other site on the server. A poorly optimized plugin on site A degrades performance on site B.
Security bleed: if one WordPress install gets compromised — via a vulnerable plugin, a weak password, or an outdated core version — an attacker who gains file system access can often read files from other sites on the same server.
PHP version conflicts: site A needs PHP 7.4 for an old plugin. Site B needs PHP 8.2 for a newer one. On shared hosting, you pick one.
Database exposure: shared database servers mean one misconfigured user permission can expose other sites' data.
Docker containers solve all of these at the infrastructure level.
What a container actually is
A Docker container is a lightweight, isolated process that has its own:
- File system (the container can't see files outside its boundaries)
- Network stack (its own IP address, its own ports)
- Process space (it can't see other containers' processes)
- Resource limits (CPU and memory caps)
It shares the host kernel with other containers, but everything above the kernel is isolated. It's not a full virtual machine — it starts in seconds, not minutes, and uses a fraction of the resources.
For WordPress, a single container runs: Nginx, PHP-FPM, and WordPress files. The database runs in a separate container, connected only to that specific WordPress container.
How NoDevZone provisions a site
When you create a new client site in NoDevZone, here's what happens in under 45 seconds:
- A new Docker container is spun up from a base WordPress image
- WordPress is configured with a fresh database on the shared MariaDB instance (isolated to that container's credentials)
- The NoDevZone plugin is automatically installed and activated
- An Nginx virtual host is configured with the client's subdomain
- SSL is issued via Let's Encrypt
- The container is registered in the reverse proxy with the correct routing rules
The client gets a URL like clientname.nodevzone.com that's live within 45 seconds of clicking "Create site." No manual server configuration, no SSH, no DNS waiting period (for the subdomain — custom domain DNS propagation is separate).
Container isolation in practice
Memory limits: each container has a configurable memory cap. If a runaway plugin causes a memory spike on one client's site, it cannot consume memory allocated to other containers. The site may slow down or return a 503 — but it won't affect other clients.
File system isolation: the WordPress files for client A are completely invisible to client B's container. A compromised plugin on client A's site has no path to client B's files.
Network isolation: containers communicate only through defined network bridges. The database container for client A accepts connections only from client A's WordPress container — not from any other container on the system.
PHP per container: because each container runs its own PHP-FPM instance, you can run different PHP versions for different clients. Client A's legacy plugin that needs PHP 7.4 runs fine alongside client B's modern stack on PHP 8.2.
Custom domains
The default setup gives every client a *.nodevzone.com subdomain. For clients who want their own domain, the process is:
- Client points their domain's A record to the NoDevZone server IP
- In the NoDevZone dashboard, you enter the custom domain
- The reverse proxy configuration is updated automatically
- SSL is issued for the custom domain via Let's Encrypt
The WordPress siteurl and home options are updated to match. From the client's perspective, their site just works at their domain — no redirect, no subdomain visible to visitors.
What this means for agencies
The practical benefit for agencies running multiple client sites:
Onboarding speed: provisioning a new client site takes under a minute. No server setup, no cPanel, no manual WordPress install.
Client separation: each client's site is genuinely isolated. A client who installs a problematic plugin affects only their own site.
Scalability: adding a new client doesn't require provisioning a new server. The container infrastructure scales to the host's capacity, and adding more capacity is a matter of adding more host nodes.
Disaster recovery: because each site is containerized, backup and restore operates at the container level. Restoring a single client's site doesn't affect any other clients.
The tradeoff is that container hosting costs more per site than shared hosting. But for agencies where site reliability and client separation are non-negotiable, the economics work out — especially when the provisioning time savings are factored in.