There are all sorts of ways you can improve the management of customer WP sites. You can put each site in its own small VM, with caching, with FrankenPHP, set that up with cloud-init, manage the entire fleet remotely with WP-CLI, etc.

You can have your own themes, lock down your plugin choices, only use your own code in functionality plugins, all that.

But if your customers can administer the sites, something is going to burn you nonetheless, and when it happens nobody is paying.

Part of it is just that WordPress exists in the middle of the continuum between content and functionality, part of it is the odd mix of users: you can have technically unaware users who you inadvertently empower to make bad decisions. It’s not their fault: it’s an over-permissive architecture.

WordPress, in your own careful hands, can run brilliantly for years. In all the time I have run it (18 years now) my own sites have been fast, busy, stable, reliable: I have even run WP brochure sites for finance industry clients, and I have had full confidence in them.

But if you’re not going to be in charge of it, don’t run it. Because really no amount of monitoring and security mechanisms can stop this eventually happening.

Ultimately I have also decided I am not going to roll out any new WP sites that I have to maintain. But then (despite my admiration for Laravel) I am going to get out of using scripting languages for server side code at all. AI is going to make all internet-facing interpreters dangerous. It’s too large a surface and I don’t have the energy for php2shell Groundhog Day.

[0] https://news.ycombinator.com/item?id=50256725