How Agiler's Container Architecture Makes Serverless WordPress Actually Work
I spent several years running WordPress on traditional hosting before we built Agiler. You know that feeling: write some code on your laptop, deploy to a server, everything works fine. Then traffic scales, and suddenly you’re hunting connection pooling bugs, fighting OOM killers, and wondering why your database is eating 90% of CPU trying to manage connections from a random 3 AM spike.
The real problem isn’t PHP or WordPress. It’s that WordPress wants two completely different things at the same time. A stateless application layer that scales with spiky traffic. And a stateful database that needs to stay alive and consistent. Traditional hosting forces you to pick one or the other. Agiler figured out how to have both.
That’s what I want to walk you through today: how we use two fundamentally different container types, plus a custom filesystem layer, to make serverless WordPress work. No plugin rewrites. No code changes.
The Core Insight: Two Kinds of Containers
Most serverless platforms treat everything as stateless. Functions come and go. They’re supposed to be fast, disposable, scale horizontally to handle any load. That works great until you bolt a database onto it. Then you’re managing connection storms and thundering herds.
Agiler doesn’t force that constraint. We built the platform on a simple principle: use the right tool for the right job.
PHP Containers: The Stateless Workers
These actually run your WordPress code. When a request comes in, one of these containers handles it. Ephemeral. No state. Spin up, handle the request, go away when traffic stops.
Each PHP container runs nginx and php-fpm in an isolated container. It’s a full WordPress runtime environment, the same stack you’d run on a traditional server, just wrapped in a container that the platform manages for you.
The platform maintains a pool of warm containers: ready-to-go containers sitting idle, waiting for requests. When a request arrives, we grab one from the pool. If the pool runs low and traffic keeps coming, we create new ones on the fly. Cold starts only happen when the warm pool is exhausted. Most of the time, especially with predictable or gradually ramping traffic, you’re hitting warm containers that are already booted and ready.
These containers scale horizontally. More traffic means more containers, spread across multiple physical servers automatically. When traffic drops, containers get recycled. The platform monitors resource pressure and adjusts the pool size accordingly, spinning up new containers when there’s capacity and reclaiming them when resources get tight.
Each container is fully isolated from every other container on the server. Your site can’t see your neighbor’s traffic, and their site can’t see yours.
MariaDB Containers: The Durable Object
In serverless architecture, there’s a pattern called a “durable object”: a single-instance, long-lived resource that persists while stateless workers scale around it. Cloudflare popularized the term with Workers, but the idea is older. In a world of ephemeral, stateless containers, you need one reliable thing that actually sticks around.
WordPress needs a database. Not a different database for each request. One consistent data store that all your PHP containers connect to. That’s your durable object.
Agiler’s MariaDB container is exactly that. One per WordPress project. Not one per server, not one per request. One per project. It doesn’t scale horizontally. It scales vertically. As more PHP containers spin up and connect to the database, the MariaDB container gets more memory and more CPU. When connections drop, it scales back down.
The platform tracks connections per project and adjusts resources automatically. If connection count is climbing, the database gets more capacity. If it’s idle, it shrinks back down. The database container sticks around as long as there’s activity, but idle databases don’t linger forever. After a period of inactivity, the container shuts down and resources are freed.
The platform also prevents thundering herds on database startup. If 50 requests arrive at once for a project whose database isn’t running, the platform doesn’t try to boot 50 databases. It coordinates a single startup and queues the requests.
PHP containers get their database connection info automatically when they start. If connection details change as the platform scales, PHP reloads its config without dropping in-flight requests.
The Persistent Storage Layer
Here’s the issue with serverless and WordPress: WordPress expects a filesystem. Plugins write cache files. Themes have image assets. The wp-config.php file has to exist. But if containers are ephemeral and disappear when traffic drops, where do those files live?
Agiler solves this with a custom persistent storage layer. Your entire WordPress project (code, plugins, themes, wp-config, uploads, everything) lives in cloud storage. When a PHP container starts, the platform mounts your project files into the container. WordPress sees a normal Linux filesystem. It doesn’t know the underlying storage is in the cloud. It can write files, read files, create directories. Everything works.
This is what lets you run WordPress unmodified on this architecture. No special plugins. No API calls instead of filesystem operations. WordPress sees a filesystem and works normally.
How It All Fits Together: The Request Flow
Let’s trace what happens when a request comes in.
An HTTP request arrives at the router, which identifies your project.
The router asks the available servers which ones have capacity. Each server responds with a score based on current load. Lower scores mean more available resources.
The router picks the best option. If there’s a warm container already set up for your project, that wins. Cold starts get deprioritized. The scoring is designed to route requests to the least-loaded server with the warmest container available.
If it’s a warm container (the common case), your project files are already mounted, the database connection is ready. Everything’s sitting there waiting.
If it’s a cold start, the container boots, your project files get mounted from cloud storage, and the database connection gets configured.
The router sends the HTTP request to the container’s nginx, which routes to php-fpm, which runs WordPress.
PHP executes your code, connects to the MariaDB durable object, queries data, builds a page.
The response comes back through the chain.
The container goes back to the warm pool, ready for the next request. Or if it’s running an outdated configuration, it gets recycled and replaced.
On the happy path, the whole thing happens in milliseconds: warm container, warm database, request in and out. Cold starts add some latency, but they’re the exception.
What Happens When Traffic Changes
Let’s walk through a realistic scenario.
Low traffic: One warm PHP container handles requests sequentially. The database runs at a small size with minimal resources. Basically idle.
Traffic picks up: The router starts pulling from the warm pool. As the pool gets low, new containers spin up. Within seconds, you might have a handful of PHP containers across different servers, all connecting to the same MariaDB. The database sees connection count climbing and scales up: more memory, more CPU.
High traffic: PHP containers spread across multiple physical servers. The database is at or near its maximum vertical scale. Each container handles requests fast, returns connections, picks up new requests. The router makes split-second decisions about which container handles which request based on real-time load.
Traffic crashes: Requests slow down. PHP containers in the warm pool aren’t getting picked up. After a period of inactivity, they get recycled. Database connections drop. The database scales back down. Eventually you’re back to a couple of PHP containers and a small database.
No manual scaling. No capacity planning. You’re not wrestling with connection limits or hoping your database doesn’t run out of memory.
Why This Works for WordPress
Traditional serverless is designed around stateless computation. Great for API endpoints and single-purpose functions. But WordPress is a monolith. It needs several things at once: a filesystem it can write to, a persistent database connection, and a consistent runtime with nginx and php-fpm.
Agiler delivers all of them. WordPress expects to write cache files, store uploads, read plugin code. The persistent storage layer gives it that, backed by cloud storage. WordPress doesn’t know the difference.
For the database, WordPress needs a persistent connection to a reliable data store. The MariaDB durable object handles that. Always there, always connected, scaling as needed.
Each container runs nginx and php-fpm, the exact stack you’d run locally. Your plugins don’t need to know they’re in a container. Configuration files and plugin code live in cloud storage, mounted when the container starts.
This is why you can take an existing WordPress install, move it to Agiler, and it runs. No rewrites. No connection pooling hacks. Just WordPress doing WordPress things.
The Serverless Angle
This architecture works because it solves the core tension between serverless and stateful applications. Traditional serverless forces you to pick: scalable stateless functions or a database that sticks around. You don’t get both. Agiler changes that equation.
Here’s what makes it actually serverless, not just “containers somewhere”: You don’t manage servers. You don’t provision instances. You deploy code, it runs, traffic scales it, costs scale with traffic. When traffic goes to zero, you’re done paying. The PHP containers are the classic serverless story: stateless, ephemeral, horizontally scalable. The MariaDB durable object brings state into the serverless world without forcing you to rewrite everything or operate a separate database.
It’s a different approach than traditional serverless platforms. But it’s built on the same principle: hide infrastructure complexity, make scaling automatic, let developers write code. You get the simplicity and cost efficiency of serverless without having to reverse-engineer your database layer or rebuild your application from scratch.
That’s how Agiler’s container architecture makes serverless WordPress work.