Hosting tips.
Practical advice on hosting, caching, WordPress and deployments. Find the problem you want to solve, follow the checks and take what helps.
28 guides, newest work first.
zram swap on a web server: setup, numbers and rollback
Swapping to a cloud disk can make MySQL and Redis wait hundreds of microseconds per page. zram swaps to compressed RAM instead. Setup, real numbers and rollback.
Self-hosted WordPress: eight WP-CLI checks for speed and safety
Eight practical checks for WordPress on your own server: verify core files, run cron properly, find autoload bloat, lock down editing, use an object cache and update with a way back.
Warm every cache variant you actually serve
A deployment can refresh the desktop page while a phone still receives an older cached copy. I make the warmer follow the same choices as real requests.
Running Varnish in front of a Redis page cache, without stale pages
Varnish and a Redis page cache can make WordPress very fast together, but only if they purge as one. The VCL and purge rules that keep both caches honest.
The first add to basket is a cache test
I test the moment an anonymous browser becomes a shopper with a basket. A fast cached product page does not prove that transition works.
Test deployments as the web server user
A release can pass checks in an administrator’s shell and still fail for the account which serves the shop. I check both the runtime and its access.
Move WordPress media to object storage and a CDN safely
How to move a site’s images to private object storage behind a CDN, rewrite the links, and only delete local copies once every file has been checked.
Lock your origin server to Cloudflare with nginx
Proxying through Cloudflare only hides your server if the server refuses everyone else. How to lock an nginx origin to Cloudflare and stop visitors faking their IP.
Ten Linux server habits: disk, logs, updates, SSH and timers
Simple, repeatable checks for anyone running a Linux server: what is listening, what is filling the disk, automatic security updates, SSH keys, systemd timers and more.
Caching a WordPress block means keeping more than its HTML
A block can register scripts, styles and interactive state while it renders. I need those effects back on a cache hit too.
Atomic deploys with automatic rollback for PHP and WordPress
Release folders, a symlink swap that is truly atomic, rollback when a post-deploy step fails, and the OPcache and permission traps that catch people out.
Apache tuning and hardening: PHP-FPM, HTTP/2, caching and Cloudflare IPs
Practical Apache tips: switch to the event MPM with PHP-FPM, turn on HTTP/2 and Brotli, cache static files properly, read real visitor IPs behind Cloudflare and hide what should be private.
Deployment configuration needs one clear owner
Define which source owns each deployment configuration file, then test that old local copies cannot silently override an intended change.
Show what your monitoring has actually checked
Make the scope, age and missing evidence visible in a hosting status summary, so a reassuring label has something useful behind it.
Test that your Git backups can be restored
Check what a repository archive includes, verify it and practise restoring it before relying on it for recovery.
Product image regeneration needs a recovery path
Moving images to a CDN saves space on the web server. I also need a way to rebuild the sizes when the local original has gone.
Stock changes need their own cache invalidation
An order can change what a shop should display without anyone pressing Update on the product. I make the cache listen to those changes too.
Cron, wp-admin and the front end need to agree where temporary data lives
A site can have a persistent object cache and still repeat the same remote calls if some request types quietly keep transients only in memory.
Background cache refresh needs a budget too
Serving an older page briefly can keep a site responsive. Rebuilding everything at once can undo the benefit.
Move large cache clears into a background queue
Clear large caches in bounded batches, keep the admin request short and show whether the job has finished.
Test the oldest PHP version your site actually runs
A clean local lint is useful, but I also check the runtime that receives the deployment.
A shared Redis service needs boundaries for clearing as well as storing
I make a site’s cache clear stay inside that site. Prefixing writes is only half of the job.
Cache product data with its pricing context
I can reuse expensive product calculations, but only when the cache key describes the price the shopper is meant to see.
PHP in the browser and PHP in cron must agree on the cache
The same cache key is not enough. Every process that reads it has to understand the value written underneath it.
A slow cache should not hold the whole site hostage
I put a time budget around Redis so that a temporary cache problem does not quietly occupy every PHP worker.
Keep a rollback route when moving PHP
I move the web server onto a separately tested PHP runtime, keep a clear route back, and check cron and background work as part of the change.
Check the Apache configuration that is actually loaded
Before changing an Apache limit, I trace the running service to the configuration it reads. A plausible file in the right directory can still be inactive.
Check that scheduled WordPress jobs actually finish
Moving WordPress cron to a server timer can make the trigger more dependable. I still check the queue, the job’s progress and the result people see.
No guides match those filters. Try another topic or reset the filters.
LET’S TALK
Want a server set up like this?
We run sites on a stack built with these habits. Tell us about yours and we’ll give you a straight answer about fit.