DEV Community: Karl Kubelet

TIL snippets/fastcgi-php.conf

Karl Kubelet — Thu, 11 Sep 2025 11:20:45 +0000

For many many years, my PHP location in Nginx looked like this:

location ~ \.php$ {
    include snippets/fastcgi-php.conf;
    fastcgi_pass unix:/var/run/php/php-fpm.sock;
    fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
    include fastcgi_params;
}

I never questioned it, it's just been copy-pasted a billion times over and over from thousands of online resources with PHP and WordPress tutorials.

Today, while writing the Nginx configuration lesson, I decided to question it, and tried to understand what every single line does, and why it's necessary.

Turns out, it's mostly redundant. The fastcgi-php.conf snippet was created for admins to avoid having to define a SCRIPT_FILENAME (and PATH_INFO in some older tutorials) manually, as well as include the default fastcgi_params.

Not sure why so many tutorials decided to add this snippet, without removing the redundant bits. My new location block now looks like this:

location ~ \.php$ {
    include snippets/fastcgi-php.conf;
    fastcgi_pass unix:/var/run/php/php-fpm.sock;
}

And this makes me happy.

Sometimes it's worth questioning things we do a certain way, simply because we've been doing them this way for many years.

Self-hosting WordPress

Karl Kubelet — Sat, 06 Sep 2025 10:13:04 +0000

I do consulting for some mid to large organizations using WordPress and WooCommerce, and last week I've successfully migrated yet another site from a top-tier reputable managed WordPress hosting provider, to a small dedicated server for half the monthly cost.

Not a particularly lightweight site. We've got WooCommerce with some paid plugins from the Woo marketplace. We have some marketing slop too. The site was struggling with performance and often down during peak hours. The few messages in their managed hosting support history are all prompting them for an upgrade to a $400/mo plan.

So we got a Ryzen 9 9900X for about $220/mo. Here are the stats from a week of production traffic to their WooCommerce site:

15m load average: 3.50 of 24.0 or 15%
database load: ~ 40% of the allocated 4 cores
disk io, network, etc: negligible
uncached avg. response time: 534ms
cached avg. response time: 19ms

We've yet to see some stats from a full list email blast, which they had on pause for the past six months, but should resume shortly after this migration is finalized.

No crappy plugins were deactivated during this migration. Except the ones forced down from their previous provider of course. They're using WP Rocket for their caching needs, which they were not allowed to do before because their provider had their own "optimal" implementation which had about a 4% overall hit rate.

Other than that the setup is pretty standard Nginx with PHP-FPM and MariaDB. This is not rocket science.

I'm currently working on a self-hosting WordPress course where I cover this and a lot more. I've already published 18 free lessons to get your started.

End-to-end open source. Self-hosting is the future.

Why you SHOULD NOT host WordPress in Kubernetes

Karl Kubelet — Sun, 22 Sep 2024 10:37:28 +0000

I'm a big fan of Kubernetes. In fact, I'm working on a complete guide to running WordPress in Kubernetes. A proper one, with horizontal scaling and everything. However, time and time again I come across individuals and organizations, wishing to run WordPress in a Kubernetes cluster without any good reasons to do it.

The Complexity Overhead

Let's get one thing straight: Kubernetes is powerful. It's fantastic for applications that need to scale dynamically, have complex infrastructure requirements, or benefit from microservices. But does WordPress really need all that?

For most WordPress sites, Kubernetes adds a mountain of unnecessary complexity. What could be handled with a simple LAMP stack on a $5/month shared hosting plan suddenly requires managing:

Persistent storage: WordPress needs reliable storage for media files and user uploads. Kubernetes doesn't natively deal with that, so you'll have to figure out how to manage volumes, backups, and recoveries. Good luck getting that right in one go!

Database scaling and backups: Sure, you could run MySQL in a Kubernetes pod, but then you're also responsible for scaling, replication, and backing it up. Isn't that what managed database services are for?

Networking and load balancing: Kubernetes offers a great abstraction layer for handling network traffic, but in most cases, WordPress needs something much simpler. Setting up ingress controllers, configuring SSL certificates, and balancing traffic across multiple instances is often overkill when you could just be using a managed load balancer—or, in the case of a small site, just relying on your basic shared hosting's built-in support.

Every layer you add means more things to configure, more things that can go wrong, and ultimately more things you (or your team) need to maintain.

And we haven't even talked about the learning curve. Unless your team is already experienced with Kubernetes, expect to spend a lot of time learning how to operate clusters, troubleshoot pod failures, and work out issues like container restarts or misconfigured services. All of this time could be spent doing something more useful—like, I don't know, building a better WordPress site?

The Cost Factor

Let's not forget the money side of things. Shared hosting plans are dirt cheap for what they offer: one-click WordPress installs, automatic updates, free SSL certificates, backups, and more. You can get a WordPress site up and running for $5–$10 a month without any headaches.

Now, compare that to Kubernetes.

First, you'll need cloud infrastructure to host your Kubernetes cluster. Depending on your cloud provider, you're looking at costs for compute, storage, and bandwidth. These won't be massive for a small WordPress site, but you're already far beyond what you'd pay for a basic hosting plan.

Then you need to manage the cluster itself. Managed Kubernetes services (like GKE, EKS, or AKS) simplify the control plane, but they come with their own costs. And if you're running this on-premise? Get ready to spend a fortune on hardware, not to mention ongoing operational costs.

Add the hidden costs of maintaining the cluster: hiring or training staff to manage Kubernetes, setting up monitoring and alerting systems, and troubleshooting issues as they arise. Suddenly, that "cool" Kubernetes project starts feeling like an unnecessary financial drain.

At this point, you're probably spending more in a month than you would in a year on shared hosting—and for what? Slightly better uptime? Scalability you don't need?

When Does It Make Sense?

Now, don't get me wrong—there are times when running WordPress on Kubernetes can make sense. Maybe you have a high-traffic website where downtime is unacceptable, and you need the horizontal scaling that Kubernetes offers. Or maybe your team already has deep expertise in Kubernetes, and you can run everything in-house without much extra effort.

But for most websites, the added complexity and cost of Kubernetes just aren't worth it. If you're running a blog, a small business site, or even a mid-sized eCommerce store, you're probably better off with traditional hosting. It's cheaper, simpler, and significantly less of a headache.

Closing thoughts

At the end of the day, just because Kubernetes can run WordPress doesn't mean it should. While I'm all for innovation and pushing the boundaries of what's possible, we need to be realistic about the cost and complexity involved. Running WordPress on Kubernetes is like driving a Formula 1 car to pick up groceries — it's a bit overkill, expensive, and will likely cause you more trouble than it's worth.

So before you jump on the Kubernetes bandwagon, ask yourself: Do you really need it? Or are you just creating a solution that's way more complicated than the problem requires?

Sometimes, simple really is better.

P.S. I'm Karl. Follow me if you're interested in WordPress, Kubernetes, Scaling, Performance, DevOps and those other geeky things.