Last week I moved a VPS carrying several live client sites onto new hardware. An AI agent did essentially all of the typing. That part was unremarkable, which is the interesting bit: shell work is well-trodden ground and an agent with a real terminal is genuinely good at it.
What was not unremarkable is how things broke. Three separate problems surfaced, and all three were the same shape.
The webserver that ignored a directive
The new box was provisioned with OpenLiteSpeed. Faster, in benchmarks, and the control panel offers it as a first-class option.
Sites came up. Pages rendered. Then compression stopped working, and nothing said so.
The cause is that OpenLiteSpeed does not implement Apache’s mod_headers. The
performance plugin these sites use emits its gzip and cache directives through
.htaccess, and OpenLiteSpeed reads that file, finds directives it does not
support, and moves on without complaint. No error. No warning. A .htaccess full
of instructions that were being read and discarded.
The cache rule that had been lying for a year
Separately, one site had a recurring bug: occasionally it would load as a white page with no styling. It had been blamed on the performance plugin for months, and every round of “fixing” the plugin made it go away for a while.
It was never the plugin. A Cloudflare static-file rule had been pinning CSS with
override_origin for about a year. Whatever cache lifetime the origin asked for was
being overruled at the edge, so a stylesheet could outlive the markup that referenced
it. The white page was a stale CSS file paired with fresh HTML.
Every round of fixing the plugin made it go away for a while, which is exactly what kept the real cause hidden.
Purging the cache “fixed” it every time, which is precisely why nobody looked further. A fix that works is very hard to argue with, even when it is treating a symptom.
The rule change that changed nothing
Then the third one, which is almost funny.
We corrected the cache rule. Verified the new rule was live. Loaded the site. Same white page.
A cache-rule change only applies to new objects. Everything already sitting at the edge keeps the behaviour it was cached under, indefinitely. The rule was right, the config was right, and the thing being served was a year-old object that had never heard of it.
There is a second trap stacked on top: curl from a laptop hits one edge location.
A green result proves that one point of presence agrees with you. Verification has to
come from something that samples more than one, or you are testing your nearest
datacentre and calling it the internet.
What actually generalises
The agent was not the problem and it was not really the hero either. It was fast at the mechanical work and it did not get bored, which matters more than it sounds during a migration.
The pattern worth carrying is that all three failures reported success. A
.htaccess that is read and ignored. A cache rule that is live and inapplicable. A
curl that is green for one PoP. None of them threw an error, and an agent optimising
for “the command exited zero” will sail straight past all three, exactly as a person
in a hurry would.
So the useful question during infrastructure work is not “did it succeed”. It is “what would this look like if it had quietly done nothing?” If the answer is “the same”, you do not have a check yet.
Sources
- Apache mod_headers documentationApache HTTP Server Project
- Cache rules and origin cache controlCloudflare