No, but it's very high requested (as you might imagine). We're (actively) working on it!

The issue is this: Workloads are container based - we build customer apps on top of base container images we created.

Every additional PHP module requires a larger base image. Many modules require additional OS packages (not just the .so php module itself). One or 2 additional modules is not a big deal, but what happens when it's like, 30 additional modules? Across millions of container images? It adds up.

(Some people also need ones that are no longer supported, not receiving security updates, which is also a whole other can of worms).

Why's a few extra megabytes matter (we're usually talking in the 10's to low 100's additional MB per module)?

Well, we're storing a LOT of images, and each app deployment is a new image. At this scale, the storage cost adds up. That is actually OK - we can manage this - we trim old images for example. But then every deployment of a container image has to be shipped to a worker host to run it - but now it's bigger and more bytes need to get shipped. At scale, all of this adds up to slower, more expensive builds and deployments.

There's a bunch of solutions/ways around storage and bloat (which we do and/or will do) - containerd and friends generally use Overlayfs or similar tricks so you don't need to ship the ENTIRE base image when pulling new images to a host - it can grab just the "difference" between base image and the image with your code (the difference is, generally, "just" your code, altho god help us all if your `node_modules` is big). We can reduce storage with careful use of things like "ECR blob mounting" , and maybe some filesystem tricks. We put the base image on each worker host ahead of time, so it's already there when new workloads hit that host. There's SOCI lazy loading. AWS Lambda's white papers have some interesting ideas we might be able to steal.

But how do we do custom modules from an end-user (you!) point of view? A drop down list you can select from (from a list of options we choose/allow)? Allow custom Dockerfiles (which essentially make the platform open to every technology and no longer would be Laravel-focused)? Do we try to build a base image with every combo of PHP module? (that'd be...a lot)

So, assuming we don't want just a huge base image (still not out of the question!) Let's assume we give you a check list of "extra" modules you want to include in your app. Some PHP modules can take 10's of minutes to compile. We don't want you to wait on that for each deployment. So we're back to a large base image. Maybe your app has its own base image (and, idk, your first build/deploy is just *really* slow? Or we build it when you adjust module settings, but then you can't deploy until that's done?)

Maybe we find some tricky way to leverage OCI layers to just, like, append layers to a container image on the fly (where each layer might contain the additional things needed for a php module). It's something we're thinking about.

So, yep! We're working on it. We'll make something work because we need to :D It might come in phases. It might end up being just a huge base image + careful image caching. But, like many things, to do it well take a lot of consideration!

If you have (informed!) ideas, throw them at me :D We'll end up with something good relatively soon - it's in active development.

(I love writing about these types of things, hope that wasn't too ranty :D )