Every few months someone publishes a tutorial on running WordPress on AWS Lambda. The pitch is always the same: automatic scaling, pay-per-request pricing, no servers to manage. It sounds great until you actually try to run a WordPress site this way.
We explored this path when we were building Agiler. We spent time with Bref, Ymir, and a few hand-rolled setups. What we found is that Lambda and WordPress want fundamentally different things from their infrastructure, and the effort required to bridge that gap isn’t worth the trade-offs.
The read-only filesystem breaks everything users care about
WordPress was designed for shared hosting in 2003. It assumes it can write to the local filesystem whenever it wants. Plugin installs? WordPress downloads a zip, extracts it into wp-content/plugins/, done. Theme updates, core updates, media uploads – all write to disk.
Lambda’s filesystem is read-only. There’s a /tmp directory that allows writes, but it doesn’t persist between invocations and has a 512MB limit (10GB if you configure ephemeral storage).
This means wp-admin, the interface most WordPress users interact with daily, is fundamentally broken. You can’t install a plugin by clicking “Install.” You can’t upload an image by dragging it into a post. You can’t click “Update Now” when WordPress tells you a new version is available. Every one of those actions tries to write to disk and fails.
The workarounds are painful. Media uploads get rerouted to S3 with a plugin. Plugin and theme changes require rebuilding the entire Lambda deployment package, usually through a CI pipeline. Core updates work the same way – you run wp-cli locally, update the package, redeploy.
A developer who lives in the terminal might tolerate this. But most WordPress users chose WordPress precisely because they don’t want to think about deployment pipelines. Telling them they need CI/CD to install a contact form plugin isn’t a good answer.
Your “serverless” database still costs $50/month
Lambda is serverless. MySQL is not. WordPress needs a relational database, and that database has to be running before any Lambda function can respond to a request.
Most Lambda-WordPress setups use Amazon RDS, starting at about $15/month for the smallest instance. But here’s where it gets expensive: if your Lambda function runs in a VPC (which it needs to for private database access), you also need a NAT Gateway for outbound internet access. That’s another $32/month plus data transfer fees.
So before serving a single page view, your serverless WordPress setup has a fixed monthly floor of roughly $47-50. That’s in the range of a fully managed WordPress host that handles everything for you.
Aurora Serverless can scale to zero, which helps on the compute side, but it doesn’t support public access. You’re still stuck in a VPC with a NAT Gateway. And Aurora Serverless has its own quirks – scale-up latency when it wakes from zero can add seconds to your first request.
There are escape hatches. SQLite stored on S3 eliminates the database server entirely, but it falls apart with concurrent writes. If two editors save posts at the same time, or your WooCommerce store processes two orders simultaneously, one of those writes may fail. That’s not a limitation most site owners are prepared to deal with.
Cold starts hit harder than you think
AWS has made real progress on cold starts. VPC cold starts used to take 10+ seconds; with Hyperplane ENIs, they’re under a second now. That sounds fine in isolation.
But a WordPress request isn’t just a function invocation. It’s PHP booting, loading autoloaders, initializing dozens of plugins, connecting to the database, running queries, and rendering a template. A warm Lambda handles this in a few hundred milliseconds. A cold start adds function initialization time on top of all that, and the result is a page load that feels slow.
Most WordPress sites don’t have constant traffic. They have bursts (someone shared a link, a newsletter went out) separated by quiet periods. During those quiet periods, Lambda functions get recycled. When traffic returns, the first visitors eat cold starts.
Provisioned Concurrency fixes this by keeping environments warm, but it costs money whether requests come in or not. Five provisioned instances with 1GB memory runs about $220/month. At that price point, you’re paying more than an equivalent EC2 instance and getting less flexibility.
Nine services where one machine used to do
A serverless WordPress stack requires Lambda for compute, API Gateway for HTTP, S3 for static assets and media, CloudFront for CDN, RDS or Aurora for the database, possibly EFS for shared storage, a NAT Gateway for networking, IAM for permissions, and CloudWatch for logs.
That’s nine AWS services minimum. Each has its own pricing model, its own configuration surface, and its own failure modes. When a page loads slowly, you might be debugging Lambda execution duration, API Gateway latency, database connection pooling, S3 access patterns, or some combination of all four.
Compare that to a single VM running nginx, PHP-FPM, and MySQL. Every WordPress developer alive knows how to troubleshoot that stack. Slow page? Check PHP logs, look at slow queries, watch resource usage. Everything is in one place.
The complexity isn’t just operational. It’s cognitive. You have to understand how all nine services interact, how their pricing compounds, and how failures cascade between them. That’s a lot of overhead for hosting a CMS.
What we do instead
When we built Agiler, we wanted the scaling properties people associate with serverless, but without giving up the things WordPress actually needs.
Our approach has three parts. Serverless containers handle the compute – they scale out with traffic and scale back down when it’s quiet, so you’re not paying for idle servers. Each WordPress site gets its own dedicated database instance through durable objects, which means no shared connection pools, no noisy-neighbor problems, and no connection limits imposed by a multi-tenant RDS setup. And a persistent storage layer gives every site a real, writable filesystem that survives restarts and deployments.
The result is that wp-admin works normally. Plugins install with a click. Media uploads work by dragging files into the editor. Updates happen through the dashboard. No deployment pipelines, no S3 rerouting, no workarounds. WordPress sees what it expects – a server with a filesystem, a database, and a PHP runtime – even though the infrastructure underneath is scaling dynamically.
The uncomfortable truth
Serverless WordPress on Lambda works as a proof of concept. The engineers behind Bref, Ymir, and ServerlessWP have done impressive work making it function at all. But “it functions” is a low bar for a production hosting environment.
WordPress needs a writable filesystem, a reliable database, and an admin panel that works without a CI pipeline. Lambda provides none of these by default, and the workarounds for each one add cost, complexity, and fragility.
If you’re evaluating WordPress hosting, ask yourself what you actually need. If the answer involves installing plugins from the dashboard, uploading images, and not worrying about NAT Gateway pricing, serverless Lambda probably isn’t it.