Is Payload suitable for deploying on serverless platforms?

[PegasisForever]

I'm planning to containerize payload using docker and deploy it on GCP Cloud Run.

I want to make sure payload is designed to handle multiple instances running together against a single database?

[DanRibbens]

Yes, docker is a great way to host Payload. I don't see any reason why GCP Cloud Run wouldn't work. If you have trouble, loop us in!

One thing to plan for is if you have file uploads, make sure those are going somewhere permanent, this is discusssed in the docs: https://payloadcms.com/docs/production/deployment#file-storage

I want to make sure payload is designed to handle multiple instances running together against a single database?

You can!

[jeanbmar]

@PegasisForever, we are using a Serverless deployment of Payload on AWS Lambda and we aren't happy about it:

1. Payload is intended to be built on the server where it's deployed, so it's shipped with dev dependencies that increase its size (see Payload size is big #332).
   It's a problem for AWS Lambda which has a 250 MB limit, so we have to delete manually the dependencies that should be dev dependencies after building locally.
   It won't be an issue for you since you use Docker but I wanted to state this for people who are going to read this in the future.
   IMO dev dependencies should be shipped as dev dependencies and Payload should be built by CI/CD and not on the production server directly.

2. If your model contains relationships, Payload is going to perform dozens of simultaneous requests when you edit a CMS entry, that will spawn many cloud functions in parallel, each one of them doing a cold start. It makes the loading of pages super slow, actually so slow that our team is now working with a local version of Payload connected to the production database to speed up things.

3. If you are building a website on top of Serverless Payload from a service like Vercel, it is going to send hundreds of simultaneous requests to build pages, and each requests is going to take db connection slots so you will need to be carefull depending on your MongoDB plan.
   If you are using a lot of relationships, some pages will take an enormous amount of time to build (see Severe performance issues #483) and this can trigger building timeouts.
   This is not an issue on a server setup because heavy queries can be cached and MongoDB connection pool increased.

If we had to do it all again from the beginning we would go with a regular server approach.

[PegasisForever]

I haven't started deploying yet, but threatically cloud run should solve the chanllenges you met:

1. Like you said, cloud run uses docker and there's no size limit
2. One running cloud run instance can process multiple concurrent requests, so only one cold start is required

That said, I still need to test it to see how good (or bad) it performs.

[jeanbmar]

Right I just read about GCP Cloud Run and it would be more suitable than AWS Lambda definitely for this use case!

[jeiksegovia]

hi @jeanbmar, any update regarding Payload performance using AWS lambda?
I opened a discussion focused on AWS lambda optimization. #1587

[PegasisForever]

Update: I deployed payload on cloud run and it worked flawlessly. Only one cold start is needed for the initial login page.

However my schema is quite simple so your mileage may vary.