🖥️

Chapter 1: Server & Hosting Environment

The host you pick shapes what the rest of this book can actually do. Later chapters assume a foundation that isn't working against you.

Managed or self managed

The first decision you'll make is also one of the most consequential. Managed hosting means somebody else handles the server layer. Self managed means it is on you.

Neither is wrong. They suit very different situations.

Managed hosting is the right pick 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 week. Providers like Kinsta, WP Engine, and Cloudways take care of OS updates, PHP versioning, firewalls, and usually daily backups. You're paying for the peace of mind, and for most small business owners it earns that.

Self managed hosting, which usually means a VPS from providers like DigitalOcean, Linode (now Akamai), Hetzner, or Vultr, gives you full control. You pick the stack, you configure everything, you keep it patched. Cheaper per resource. The total cost of ownership goes up the moment something breaks and you are googling nginx error logs at midnight.

A rule of thumb: if the site generates revenue and you don't have sysadmin experience, go with 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. The long term support releases (currently 22.04, with 24.04 gaining traction) give you five years of security patches and a large community behind them. Debian is equally valid. Avoid anything past end of life, because an unpatched OS undoes whatever you do above it.

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. Minor inconvenience at first, but you end up with a leaner, faster setup.

Apache is older and more permissive. The .htaccess support cuts both ways. It makes WordPress configuration portable and convenient, but it also lets WordPress and plugins drop configuration files anywhere in the document root, which brings 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 configured properly.

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. 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 can replace MySQL without any configuration changes 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 past 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. Enforce SSH key authentication and disable password authentication entirely. This is not optional.

  • Configure a firewall - UFW on Ubuntu makes this straightforward. Allow SSH (on a port other than 22 if you prefer), HTTP, and HTTPS. Block everything else.

      ufw allow 22/tcp
  ufw allow 80/tcp
  ufw allow 443/tcp
  ufw enable

  • Keep 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-upgrades

  • Use a different 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 to 65535 range and update your firewall rule.

  • Hide the web server version - By default, Nginx advertises its exact version in response headers and default error pages. That's a free fingerprint for anyone scanning for known vulnerabilities in specific versions. Inside the http {} block in /etc/nginx/nginx.conf, set:

      server_tokens off;

    Apache's equivalent is ServerTokens Prod and ServerSignature Off in the main config. Same idea, same reason.

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 rather than the browser. Displaying them in production leaks information about your file structure and your database.
  • post_max_size and upload_max_filesize - Set these to something sensible for your use case. The defaults 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

Hosts vary wildly. Some of the cheaper options look attractive up front and 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 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 with it. This is the "bad neighbour" problem, and it happens regularly on cheap shared hosting.
  • No backups, or backups stored on the same server - A backup living on the same server it's backing up doesn't help when that server is the problem. Chapter 11 covers proper backup strategy.

A note on WordPress multisite

WordPress Multisite lets you run a network of sites from a single WordPress installation. It's commonly used by 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, with a few additional points worth being aware of. Network administrators have elevated privileges across every site in the network, so the principle of limiting admin access applies even more strongly. Plugin and theme management happens at the network level, which means a vulnerability in a network activated plugin affects every site on the install at once. 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 deserves its own dedicated coverage. This book will expand on that in a future update. For now, treat every principle here as applying to the network level as well as to individual sites.

Summary

A well chosen, properly configured host removes a significant amount of risk before WordPress is even installed. The common mistake is treating the hosting 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 that follows assumes this foundation is solid.

Next, Chapter 2: WordPress Core Hardening.