WordPress

Last reviewed Aug 26, 2026 · 875 words

Self-hosted WordPress on a 1-vCPU, 1 GB VPS serves more traffic than most sites will ever see. What takes WordPress sites down is not load; it is the 23rd plugin, installed in a hurry, abandoned by its author and exploited 2 years later. Run WordPress as 2 containers with a short, curated plugin list and it is the easiest CMS in this catalogue to keep alive for a decade. Run it as a plugin buffet and it is the most attacked piece of software you will ever operate, which is exactly what the catalogue's "frequent target for attacks" con is describing.

Two containers and a 512 MB floor

services:
  wordpress:
    image: wordpress:php8.3-apache
    ports:
      - "127.0.0.1:8080:80"
    environment:
      WORDPRESS_DB_HOST: db
      WORDPRESS_DB_USER: wp
      WORDPRESS_DB_PASSWORD: changeme
      WORDPRESS_DB_NAME: wordpress
    volumes:
      - ./html:/var/www/html
    restart: unless-stopped
  db:
    image: mariadb:11
    environment:
      MARIADB_DATABASE: wordpress
      MARIADB_USER: wp
      MARIADB_PASSWORD: changeme
      MARIADB_ROOT_PASSWORD: change-this-too
    volumes:
      - ./db:/var/lib/mysql
    restart: unless-stopped

Put Caddy in front for TLS and bind the WordPress port to localhost, as above, so the only public path is through the proxy. The catalogue's 512 MB minimum is realistic for both containers on a quiet site; PHP workers under a traffic spike push that toward 1 GB, and a caching plugin (one, not three) keeps most requests from reaching PHP at all. On first visit the install wizard runs; complete it immediately, because an unfinished install page on a public host is an open invitation to whoever finds it first.

Attack surface scales with plugin count, not visitor count

WordPress core is patched fast and updates itself. The exploits that matter are almost all in plugins and themes, and the risk is proportional to how many you have and how many are unmaintained. My rules, in order of how much they matter: install nothing you would not miss; delete rather than deactivate, because deactivated plugin code is still on disk and still reachable; check the "last updated" date and the tested-up-to version before installing; and prefer plugins with a business behind them, because abandonment is the failure mode. Ten plugins is a full site. Thirty is a liability.

Beyond that, the defaults worth changing are small. Disable XML-RPC unless the mobile app needs it, since it is the classic brute-force vector. Put CrowdSec or fail2ban on the proxy logs to ban login-page hammering. Require 2FA for administrator accounts and give authors the Editor role, not Administrator. None of this is exotic; all of it is skipped constantly.

Replace wp-cron with a real cron

WordPress schedules its housekeeping (publishing scheduled posts, sending pings, running backup plugins) through wp-cron.php, which fires only when someone visits the site. On a low-traffic site that means scheduled posts go out late and on a busy one it means every visitor pays for a cron check. Fix both by disabling the built-in trigger and calling it from the host every 5 minutes:

// wp-config.php
define('DISABLE_WP_CRON', true);

*/5 * * * * curl -fsS https://blog.example.com/wp-cron.php?doing_wp_cron > /dev/null

This is the single change with the best effort-to-benefit ratio on a self-hosted install and almost nobody makes it.

A backup is a database dump plus wp-content, restored once

Everything you wrote is in MariaDB; everything you uploaded, plus themes and plugins, is under html/wp-content. Core files are reproducible from the image and not worth backing up.

docker compose exec db mariadb-dump -u wp -pchangeme wordpress | gzip > wp-$(date +%F).sql.gz
tar czf wp-content-$(date +%F).tar.gz html/wp-content

Ship both off the machine nightly following the 3-2-1 pattern, and do one restore into a scratch compose stack this month, because a WordPress backup that has never been restored has a way of being missing the uploads directory. Skip the backup plugins that write a zip into the same web root; they add attack surface and back up to the disk that is failing.

When Ghost is the better answer

If the site is a blog or newsletter with one or a few authors and no need for a plugin ecosystem, Ghost gives you a faster site with a smaller attack surface, built-in memberships and email, and nothing to curate. WordPress wins the moment you need a form builder, a shop, an events calendar, multilingual content or a client who already knows the WordPress admin. The CMS category lays out the others; for most people the honest choice is between these two.

What I'd do

Run the 2-container compose behind Caddy, finish the installer within 5 minutes of first start, enable core auto-updates, and cap the plugin list at 10 with every one checked for a maintainer. Disable XML-RPC, put CrowdSec on the proxy, and switch wp-cron to the host crontab in the first hour. Nightly database dump plus wp-content tarball to a second machine, one test restore a quarter. Operated like that, WordPress is boring, and boring is the highest compliment a public-facing service gets.