WordPress Serverless Hosting: The Good, The Bad, and The Ugly

Had a client call me in a full-blown panic. Their WooCommerce site went down. On Black Friday. They’d just launched a massive sale, got a huge surge of traffic, and their fancy managed hosting plan just fell over. By the time the host could scale their resources, they’d lost thousands in sales. Total mess. It’s a classic story, and it shows the fundamental problem with most so-called “scalable” WordPress serverless hosting.

My first instinct, years ago, would have been to just throw more hardware at it. Upgrade to the most expensive plan, maybe even a dedicated server. But that’s like buying a fleet of buses for a single busy weekend. It’s overkill, expensive, and it’s still not truly elastic. You’re paying for capacity you don’t need 99% of the time. There had to be a better way.

Why Traditional WordPress Hosting Fails at Scale

The issue is that most hosting is built on the idea of a server as a fixed resource. A box. When traffic spikes, that box gets overwhelmed. Managed hosts try to autoscale, but it’s often slow and clunky. It’s not designed for the instantaneous, massive peaks you see with a successful marketing campaign. You’re always reacting, and in e-commerce, if you’re reacting, you’re losing money.

This is where the concept of “serverless” comes in. The name is a bit of a lie—of course, there are still servers. The difference is you don’t manage them. At all. You upload your code, and the cloud provider (like AWS) runs it in response to requests. No traffic? You pay basically nothing. A million visitors? It scales instantly. This idea is central to what I’ve seen work, and it builds on a concept I first read about over at carlalexander.ca about building a serverless platform.

# Example serverless.yml for a WordPress site
# This isn't a complete file, just for illustration.

service: wordpress-site

provider:
  name: aws
  runtime: php-8.2
  region: us-east-1
  environment:
    DB_HOST: ${ssm:DB_HOST}
    DB_USER: ${ssm:DB_USER}

functions:
  main:
    handler: public/index.php
    layers:
      - ${bref:layer.php-82-fpm}
    events:
      - httpApi: '*'

# This is the kicker: you define your infrastructure as code.
# No more clicking around in a hosting panel.

So, What’s the Point?

Going serverless solves the scaling problem. Brilliantly. But it’s not the whole picture. Just having your PHP code run on something like AWS Lambda doesn’t automatically give you a fast, secure, professional setup. You still need to handle a bunch of other stuff:

• CDN and Asset Handling: Your images, CSS, and JS files need to be served from a CDN like CloudFront, not from the same function running WordPress.
• Database Management: You need a managed, scalable database that can keep up with the traffic.
• Deployment Pipeline: You need a reliable way to get your code from development to staging to production without wanting to pull your hair out.

That’s the real challenge: connecting all these services into a cohesive DevOps platform that’s tailored for WordPress. It’s about more than just avoiding server updates; it’s about building a professional workflow.

Look, this stuff gets complicated fast. If you’re tired of debugging someone else’s mess and just want your site to work, drop my team a line. We’ve probably seen it before.