This isn’t your grandma’s or grandpa’s LAMP stack. This is WordPress hoisted into RAM like dropping a dragster engine into a Honda Civic, running so goddamn hard it forgets what a hard drive even is. Most devs spend their days duct-taping plugins and praying that they can move the needle on their PageSpeed score. Me? I boot entire stacks straight from the void, loaded into memory, ready to die and be reborn in milliseconds.
You don’t need this. Nobody needs this. But maybe you’re here because you’re sick of latency. Sick of excuses. Sick of infrastructure that doesn’t scream when it runs.
There are two variants of “Rick” There’s the “Fred Rogers, but for business” who cares a great deal about you as a person, who gets things done with a smile; then there’s “The Hat Man” – the one you see when you take too much benadryl, the unhinged entity menacingly lurking just on the edge of your peripheral vision. This particular creation is brought to you by The Hat Man.
If you dont want to read my mad ramblings, go grtaight to the Ansible Playbook for Running WordPress from RAM (On My GitHub)
Background
Over the heap of absolutely terrible projects I have had to endure in my career, and there have been many, absolutely nothing has tried my patience quite like WordPress sites that were inherited from previous developers. Absolute garbage heaps riddled neglect and skill issues.
As I’ve gone about making vehicle fleets from junkyards, I have learned a lot about performance turning WordPress from the lens of being a linux server administrator first and WordPress dev second. WordPress itself can be made to run fast, and there are plugins that can get you there – but real speed comes from tuning the server. I’ve had people fight me tooth and nail that cache is the only way to make WordPress fast. None of those people know the first thing about administrating farms of servers at scale. Just tossing a bunch of cache plugins at WordPress doesnt do shit, and doing so leaves a lot of performance tweaks on the table.
There is a vast array of hosting companies out there that specialize in WordPress hosting, but even they only take their stack performance tuning so far. The more prominent of the WordPress hosts basically set up your site to run headless. Sure, headless wordpress is great, it has a lot of performance advantages oevr tossing a wordpress site up on a shared hosting platform, but no matter how you slice it, server still has a role! That is where all the stuff that matters happens. This is 2025, people still need to fill out forms, and Lindsey or Steve still need to log in and update content, and if you sell stuff, the checkout process needs state.
Now, how do you make speed gains without trying to do surgery on your codebase with a chainsaw? Go ahead, take that old wordpress site you just inherited, or built, and watch what happens when you update some or all of the plugins. The site breaks so fucking hard that a black hole opens up and whole cities get sucked into the event horizon that once was you updating that wierd WooCommerce plugin to the latest version. Might as well have stuck a fork in an electrical outlet.
I have been through this cycle at least 100 times. Inherit shitty old WordPress site with enough technical debt to bankrupt small nations, and the client needs this thing to run fast yesterday. And these weren’t tiny little mom and pop operations, no, these were enterprise WordPress sites with custom integrations to things like ERP systems that went extinct when the chixilub asteroid made dinosaurs taste the fucking sun. Most of the time, I’ve had to sit on these sites and keep the lights on until either the whole site could be refactored, or until such time that they finish a dependent project in house to move away from some legacy system that is talking to their website. Recently I undertook a project that inspired me to stop thinking of the traditional stack in the way that we all as WordPress devs have become accustomed to. Sometimes it takes one of these moments to really rethink what you are doing, and why. I decided that I didn’t want to be a sheep to the way of doing things and completely rethink the stack. So I did, and I did it from the perspective of a sysadmin that builds for raw speed.
... continue reading