WordPress was written for Linux. Not as a preference - as a dependency. Understanding why helps you make better decisions about where and how you host your site.
WordPress runs on PHP and talks to a MySQL-compatible database. It serves files via a web server. That combination - Linux, Apache or Nginx, MySQL/MariaDB, PHP - is commonly called the LAMP or LEMP stack, and it's what virtually every WordPress site in the world runs on.
This isn't a coincidence or a convention. WordPress was built by developers working on Linux, tested on Linux, and optimised for Linux. The file permission model, the way PHP-FPM manages worker processes, the way Nginx handles concurrent connections - all of it was designed with Linux's process model in mind.
Windows hosting for WordPress exists, but it's always an adaptation. IIS instead of Nginx, Windows file paths instead of Unix paths, different permission semantics. It works, but it introduces friction at every layer.
PHP used to run as a module inside Apache (mod_php). Every web request would spin up a PHP interpreter, load your WordPress files, execute everything, then tear it all down. Repeated for every single visitor.
PHP-FPM (FastCGI Process Manager) changes this. It maintains a pool of PHP worker processes that stay running, waiting for requests. When a visitor hits your site, a worker picks it up, runs it, and goes back to waiting. No startup overhead per request.
On Linux, this works particularly well because of how the OS manages processes and file descriptors. A properly tuned PHP-FPM pool on Linux, talking to a local Unix socket rather than a TCP port, can handle hundreds of concurrent WordPress requests on modest hardware with low latency.
Apache was the dominant web server for most of WordPress's history, and it still works well. But Nginx has largely replaced it for high-performance WordPress setups for one key reason: how it handles concurrent connections.
Apache uses a thread or process per connection. Under high load, that means hundreds of threads all consuming memory simultaneously. Nginx uses an event-driven model - a small number of worker processes can handle thousands of concurrent connections without the memory overhead.
For a typical small business WordPress site this rarely matters - you're not getting thousands of concurrent visitors. But it does matter for bots. Without Nginx's efficiency and rate-limiting capabilities, bot traffic (particularly the constant probing of wp-login.php) can cause Apache to spin up threads and consume memory even when all those requests are being rejected.
Most managed WordPress hosts run MariaDB rather than MySQL these days, including us. MariaDB is a fork of MySQL created by MySQL's original developers after Oracle acquired it. For WordPress workloads, the practical differences are minor - the query syntax is identical, the WordPress database schema works without changes - but MariaDB tends to have slightly better performance on read-heavy workloads and more active open-source development.
What matters more than MySQL vs MariaDB is where the database lives relative to your web server. If your WordPress files are on a server in Sydney but your database is in a shared cluster in Singapore (common with cheap cPanel hosting), every database query adds 80-100ms of network latency. On a typical WordPress page load, there are 20-50 database queries. The math gets ugly quickly.
Running your database on the same host as your web server, connected via a local socket, eliminates that overhead entirely.
Docker runs natively on Linux. Windows Server can run Docker containers, but there are gotchas around file system performance and process isolation that don't exist on Linux. This matters for WordPress hosting because containerisation is the right answer to a problem that's plagued shared hosting for decades: resource contention.
On traditional shared hosting, one site having a traffic spike or running a CPU-heavy operation (a bulk image resize, a WooCommerce import) affects every other site on the same server. There are soft limits, but enforcement is inconsistent and the underlying architecture doesn't isolate resources properly.
Docker containers on Linux get hard resource limits: this container gets exactly 0.09 CPU cores and 256MB RAM. No more. The kernel enforces this at the cgroup level. Your site can't starve another customer's site, and another customer's traffic spike can't slow yours down.
NVMe storage is significantly faster than SATA SSDs, and orders of magnitude faster than the spinning hard drives that cheap hosting still uses. WordPress benefits from fast storage in two ways: faster reads of PHP files and WordPress core, and faster database writes for caching, session data, and transients.
Linux's I/O scheduler is tuned for NVMe workloads. The ext4 and XFS filesystems handle the concurrent read patterns of a busy web server efficiently. On Linux with NVMe, WordPress's file system overhead is essentially negligible.
You don't need to understand any of this to run a WordPress site. But understanding it helps you ask better questions when evaluating hosting providers:
The answers tell you whether a host has made the right architectural decisions. A host running isolated Linux containers with local MariaDB, Nginx, PHP-FPM, and NVMe storage has done everything right at the infrastructure level. A host running shared cPanel on spinning disks with a remote database cluster hasn't - regardless of how competitive their prices look.
Australian WordPress hosting from $5/month
Your own containerised environment on Australian NVMe servers. Simple, fast, and genuinely cheap.