Choosing the right foundation matters more than most people realise. Get this wrong and no amount of hardening later will save you.
Managed vs Self-Managed Hosting
The first decision you'll make is also the most consequential. Managed hosting means someone else handles the server layer. Self-managed means that's on you.
Neither is wrong. But they suit very different situations.
Managed hosting is the right choice if you're running one or two sites, you'd rather focus on the business than the server, or a breach would genuinely ruin your day. Providers like Kinsta, WP Engine, and Cloudways handle OS updates, PHP versioning, firewalls, and in many cases daily backups. You're paying for that peace of mind, and for most small business owners it's worth every penny.
Self-managed hosting — a VPS from providers like DigitalOcean, Linode (now Akamai), Hetzner, or Vultr — gives you full control. You choose the stack, you configure everything, and you're responsible for keeping it patched. It's cheaper per resource, but the total cost of ownership goes up the moment something goes wrong and you're googling nginx error logs at midnight.
A reasonable rule: if the site generates revenue and you don't have sysadmin experience, use managed hosting. If you do have that experience, or are willing to develop it, a well-configured VPS will outperform most managed environments at a fraction of the cost.
Choosing the Right Stack
Operating System
Ubuntu LTS is the sensible default. Long-term support releases (currently 22.04, with 24.04 gaining traction) give you five years of security patches and a massive community behind them. Debian is equally valid. Avoid anything that's reached end-of-life — running WordPress on an unpatched OS is like leaving your front door open.
Web Server: Nginx vs Apache
Both work well with WordPress. The choice depends on what you're comfortable with and what your host supports.
Nginx handles concurrent connections more efficiently, especially under load. It has no .htaccess support, which means rewrite rules and WordPress permalinks need to be configured at the server block level. This is a minor inconvenience initially but results in a leaner, faster setup.
Apache is older and more permissive. Its .htaccess support is a double-edged sword. It makes WordPress configuration portable and convenient, but it also means WordPress (and plugins) can drop configuration files anywhere in the document root, which introduces its own risks.
For new setups, Nginx is the better choice. If you're inheriting an existing Apache server, there's no urgent reason to migrate — just make sure it's properly configured.
PHP Version
Always run a supported PHP version. As of 2026, PHP 8.3 and 8.4 are the recommended releases. PHP 8.3 is in security-only support through December 2027, and PHP 8.4 is in active support through December 2028. PHP 8.1 reached end of life on December 31, 2025 and receives no further patches. PHP 8.2 follows at the end of 2026.
WordPress officially recommends PHP 8.3 or greater. PHP 8.4 is the better choice for new setups, as it is actively maintained and major plugins have had time to catch up with compatibility. Before upgrading PHP on a production site, test in staging first. Anything that hasn't been updated in two or more years is a risk.
Running PHP 8.1 or earlier in production is not acceptable. These versions are end-of-life and receive no security patches. If a host won't let you run a current PHP version, that host is not fit for purpose.
Database
MySQL 8.0 or MariaDB 10.6+ are both solid choices. MariaDB is a drop-in replacement for MySQL and is the default on many Linux distributions. WordPress works equally well with either.
The main thing to avoid is running an outdated database version. Both MySQL 5.7 and MariaDB 10.3 are at or approaching end-of-life. Upgrade before your host or distro forces you to.
Server Configuration Basics
Once your server is provisioned, a few things should happen before WordPress is anywhere near it.
Disable root SSH login. Create a dedicated user with sudo privileges. Force key-based authentication and disable password authentication entirely. This is non-negotiable.
Configure a firewall. UFW on Ubuntu makes this straightforward. Allow SSH (on a non-standard port if you prefer), HTTP, and HTTPS. Block everything else.
ufw allow 22/tcp
ufw allow 80/tcp
ufw allow 443/tcp
ufw enableKeep the OS patched. Enable unattended upgrades for security patches on Ubuntu. It won't upgrade major versions automatically, but it will apply security fixes without you having to remember to do it.
apt install unattended-upgrades
dpkg-reconfigure --priority=low unattended-upgradesUse a non-standard SSH port. It won't stop a determined attacker, but it eliminates the constant noise of automated bots hammering port 22. Move it to something in the 49152–65535 range and update your firewall rule accordingly.
PHP Configuration
A few PHP settings matter directly for WordPress security and stability.
expose_php = Off — stops PHP from advertising its version number in HTTP response headers. Minor, but there's no reason to broadcast it.
display_errors = Off — errors should go to a log, not to the browser. Displaying errors in production leaks information about your file structure and database.
post_max_size and upload_max_filesize — set these to something sensible for your use case. Default values are often too low for WordPress media uploads. 64M is a reasonable starting point.
max_execution_time — default is 30 seconds. Some WordPress operations (large imports, backup plugins) need more. 120 to 300 seconds is a common setting, depending on your workload.
memory_limit — WordPress recommends 256M as a minimum for most sites. Busy sites with complex plugins may need more.
Hosting Red Flags
Not all hosts are equal. Some choices that look attractive on price will cost you later.
Shared hosting with no PHP version control. If you can't choose your PHP version, move on.
No SSH access. You cannot properly manage or secure a WordPress site with FTP only. SSH access is a baseline requirement.
No staging environments. You should never test updates on production. If a host doesn't offer staging, you'll need to build it yourself or use a plugin-based solution like WP Stagecoach or a tool like Local for local development.
Oversold shared environments. If your site shares a server with thousands of others and one of them gets compromised, your risk goes up. This is the "bad neighbour" problem. It's not hypothetical — it happens regularly on cheap shared hosting.
No backups, or backups stored on the same server. Covered in more depth in Chapter 11, but worth flagging now: a backup that lives on the same server it's backing up is not a backup. It's a copy.
A Note on WordPress Multisite
WordPress Multisite allows you to run a network of sites from a single WordPress installation. It's commonly used for agencies managing groups of related sites, universities with departmental sites, and enterprises with multiple brands under one platform.
The security considerations in this book apply to multisite installations as much as single-site ones, but there are some additional points worth being aware of. Network administrators have elevated privileges across all sites in the network, so the principle of limiting admin access applies even more strongly. Plugin and theme management happens at the network level, meaning a vulnerability in a network-activated plugin affects every site simultaneously. Database table prefixes are shared but each site gets its own prefix appended, so the table prefix guidance in Chapter 5 applies at installation time before the network is created.
Multisite-specific hardening is a topic that deserves its own dedicated coverage. This book will expand on it in a future update. For now, treat every principle here as applying to the network level as well as individual sites.
A well-chosen, properly configured host removes a significant portion of risk before WordPress is even installed. The most common mistake is treating this decision as purely a cost comparison. Factor in support quality, PHP flexibility, SSH access, and whether the host takes security seriously at the infrastructure level.
If you're setting up a new site today: pick a managed host if simplicity matters, or a reputable VPS provider if control does. Either way, run a supported OS, a current PHP version, and a properly configured web server. Everything in the chapters that follow assumes this foundation is solid.
Next: Chapter 2 — WordPress Core Hardening