PayloadCMS in an Enterprise AWS Environment

We needed a headless CMS that a non-technical content team could actually use, that fit inside an existing AWS infrastructure, and that wouldn't require standing up a separate identity system. PayloadCMS checked enough boxes to try.

Here's what that deployment looked like and what I'd do differently.

Infrastructure

ECS Fargate behind an Application Load Balancer, RDS PostgreSQL for the database, S3 with CloudFront for media. We picked PostgreSQL over MongoDB because the team already had RDS expertise and the query tooling is more familiar. Payload supports both, so it wasn't a hard trade-off.

Cognito handled identity via Payload's custom auth hooks. Getting that integration right took longer than expected. Payload's auth model is opinionated and the hook surface isn't fully documented for external IdP setups.

The Upload Problem

Payload's admin UI assumes a single origin. Behind a load balancer without sticky sessions, file uploads break intermittently. The multipart upload starts on one container, the completion request hits another, and Payload loses the context.

Sticky sessions in the ALB target group fixed it. This isn't obvious from the docs and it bit us in staging before we caught it.

Content Between Environments

Migrating content across dev, staging, and production needs a deliberate strategy. Payload doesn't have built-in environment sync, so we built seed scripts that pulled from environment-specific S3 buckets and seeded the target database. Tedious to set up, reliable once in place.

What I'd Do Differently

The Cognito integration added significant upfront complexity. For a project starting fresh, I'd evaluate whether Payload's built-in auth is sufficient before wiring up an external IdP. The integration works, but it required patching around some assumptions Payload makes about its own user model.