Managed WordPress hosting works fine until it doesn't. You hit traffic spikes that your plan can't handle, you need server-level access to debug a performance issue, or you're paying premium prices for a box you could run yourself at a fraction of the cost. That's when a VPS or dedicated server starts making sense — and that's when you need someone who actually knows how to manage one.

I'm Michal, a UK-based WordPress developer at Rootscope. I manage the full server stack for 70+ WordPress sites across multiple VPS and dedicated servers. From initial provisioning to ongoing maintenance, security hardening, and performance tuning — I handle the infrastructure so you can focus on running your sites.

Server Stack Expertise

I work across the control panels, web servers, and database engines that power WordPress at scale. This isn't theoretical knowledge — these are the stacks I manage daily.

Control panels: WHM/cPanel for multi-tenant hosting environments, CloudPanel for modern VPS deployments, Plesk for Windows/Linux hybrid setups. I know their strengths, their quirks, and their security pitfalls. I've investigated a CloudPanel server compromise where an attacker created an admin account through the panel — the kind of incident that teaches you where the weaknesses are.

Web servers: LiteSpeed Enterprise and OpenLiteSpeed for their WordPress-specific caching and HTTP/3 support. Nginx for high-concurrency reverse proxy setups. Apache with mod_lsapi where cPanel is in play. Each has configuration nuances that matter for WordPress — rewrite rules, cache headers, PHP handler integration, and request buffering.

Database engines: MariaDB 10.x and 11.x, MySQL 8.x. I handle installation, configuration, backup automation, replication setup, and ongoing performance tuning. For WordPress specifically, the database configuration that comes out of the box on most VPS images is inadequate — it's designed for generic workloads, not the read-heavy, write-bursty pattern WordPress and WooCommerce generate.

Caching layers: Redis for object caching (essential for WooCommerce), Memcached where Redis isn't available, LiteSpeed Cache for full-page caching, and Varnish in nginx reverse proxy configurations.

PHP-FPM Tuning for WordPress

PHP-FPM configuration is where I see the most damage on WordPress servers. The default settings on most VPS images and control panel installations are either far too conservative (slow performance under normal load) or far too aggressive (server crashes under traffic spikes).

The core calculation is straightforward but routinely ignored:

Available RAM minus MySQL memory minus OS overhead, divided by per-worker memory consumption, equals your maximum PHP-FPM workers.

On a 4GB VPS running MariaDB (allocated 1GB), with 500MB for the OS, you have roughly 2.5GB available for PHP workers. If each WordPress request consumes 80-100MB of memory (common for WooCommerce), you can sustain 25-30 workers. Set pm.max_children = 50 on that server and you'll run out of memory the moment traffic picks up — MariaDB gets killed by the OOM killer, and your site goes down.

I've written about this exact scenario in detail: a DDoS attack combined with over-provisioned PHP-FPM killed MariaDB on a 3.7GB server where pm.max_children was set to 50. The math simply didn't work.

For every server I manage, I configure:

pm.max_children based on actual available RAM and measured per-worker memory consumption
pm.start_servers, pm.min_spare_servers, and pm.max_spare_servers tuned for the site's traffic pattern — burst-heavy sites get more spare workers, steady-traffic sites run leaner
pm.max_requests to prevent memory leaks from long-running workers — typically set to 500-1000 requests before a worker is recycled
request_terminate_timeout to kill workers that get stuck on a runaway script, preventing worker pool exhaustion
PHP memory_limit set realistically — 256MB for standard WordPress, 512MB for WooCommerce with heavy import/export operations

MySQL/MariaDB Optimisation

The database is typically the bottleneck on WordPress servers, and out-of-the-box configurations make it worse. Here's what I tune:

innodb_buffer_pool_size — this is the single most impactful MySQL/MariaDB setting. It determines how much data the database can cache in RAM. The default is often 128MB, which means the database constantly reads from disk even for frequently accessed data. On a dedicated WordPress server, I set this to 50-70% of available RAM after accounting for PHP-FPM and OS requirements.

Slow query log analysis — I enable the slow query log with a 0.5-second threshold and analyse the results after 24-48 hours of normal traffic. This tells me exactly which queries need attention — missing indexes, unoptimised JOINs, full table scans on large postmeta tables. For deeper work, I offer dedicated database optimisation services.

Connection management — max_connections needs to match your PHP-FPM worker count plus a margin for admin connections and monitoring. Too low and you get "Too many connections" errors. Too high and you risk resource exhaustion. I also configure wait_timeout and interactive_timeout to clean up idle connections promptly.

InnoDB log file sizing — undersized InnoDB log files cause excessive checkpoint flushing, which degrades write performance. For WooCommerce stores with heavy write loads (order processing, Action Scheduler), properly sized log files make a meaningful difference.

Backup strategy — automated daily database dumps with compression, stored off-server. I use mariabackup or mysqldump depending on the environment, with retention policies that balance storage costs against recovery requirements. Point-in-time recovery via binary logs where the business case justifies it.

Security Hardening

Server security starts long before WordPress. If the server itself is compromised, no WordPress security plugin will help you.

SSH hardening is the first thing I configure on any new server. Key-based authentication only — password authentication disabled. Non-standard SSH port. Fail2ban to block brute force attempts. Root login disabled; a dedicated sudo user for administrative access. These basics prevent the vast majority of automated attacks.

Firewall configuration using UFW or firewalld, with a default-deny policy. Only the ports that need to be open are open: HTTP/HTTPS for the web server, the custom SSH port, and monitoring agent ports if applicable. Database ports are never exposed to the public internet.

Malware scanning and rootkit detection — I deploy rkhunter and ClamAV for scheduled scanning, with alerts on detection. I've cleaned servers with deeply embedded malware — including one incident involving a cryptominer with 14 separate persistence mechanisms that survived multiple cleanup attempts before I traced every one of them. That experience changed how I approach server auditing.

File integrity monitoring to detect unauthorised changes to system files, web server configurations, and WordPress core files. Any change outside of a known maintenance window triggers an alert.

Automatic security updates for the OS — unattended-upgrades on Debian/Ubuntu, dnf-automatic on RHEL/AlmaLinux. The server's operating system should patch itself for known vulnerabilities without waiting for manual intervention. For more comprehensive WordPress-level security, I cover that under my WordPress security monitoring service.

Monitoring Setup

You can't manage what you can't see. Every server I maintain has comprehensive monitoring covering uptime, resource usage, and service health.

Uptime Kuma for HTTP/HTTPS endpoint monitoring. Every site is checked every 60 seconds with alerting via email and Slack. I monitor not just whether the site responds, but response time thresholds — a site that's technically "up" but responding in 8 seconds needs attention before it becomes a real outage.

Telegraf + InfluxDB + Grafana for server metrics. CPU, RAM, disk I/O, network throughput, PHP-FPM pool status, MariaDB query rates, and slow query counts — all collected at 10-second intervals and visualised in Grafana dashboards. This gives me both real-time visibility and historical trend data. When a client reports "the site feels slow lately," I can look back weeks or months and see exactly when performance started degrading and correlate it with specific events.

Healthchecks.io for cron job and scheduled task monitoring. WordPress cron, backup scripts, certificate renewals, and log rotation jobs all report to Healthchecks. If a scheduled job doesn't run when expected, I get alerted. Silent failures — like a backup script that stopped working two weeks ago — are the ones that hurt most when you actually need that backup.

Log aggregation and alerting — centralised syslog for auth events, web server errors, and PHP fatal errors. I use log-based alerts for specific patterns: repeated failed SSH attempts, PHP segfaults, OOM killer invocations, and MySQL connection refusals. These are early warning signs that something is going wrong before users notice.

What's Included in Server Management

My server management service covers:

Initial server provisioning and hardening — OS installation, firewall, SSH, user setup, web server, PHP, and database configured to best practices
Ongoing OS and software updates — security patches, PHP version upgrades, database engine updates, control panel maintenance
PHP-FPM and database tuning — initial configuration based on your workload, with ongoing adjustments as traffic patterns change
Monitoring setup and response — full monitoring stack deployment with alerting and incident response during UK business hours
Backup automation — server-level and database backups with off-site storage and regular restore testing
Security incident response — if something happens, I investigate, contain, and remediate

Server management is available as an add-on to any maintenance plan or as a standalone service for agencies and businesses that manage their own WordPress sites but need someone handling the infrastructure underneath.

Running WordPress on a VPS or dedicated server gives you the control and performance that managed hosting can't match — but only if the server is properly configured and maintained. Default settings will get you online. Proper tuning will keep you there under load.

If you're running WordPress on a VPS and things aren't performing the way they should, get in touch. I'll audit your server configuration and tell you exactly what needs to change.

WordPress Server Management — VPS & Dedicated