Why Deploying NestJS on AWS Lambda with Docker is a Nightmare

🚨Do not even try to deploy your NestJS/Javascript app's on lambda through docker🚨

1. AWS Lambda Was Not Designed for Heavy Docker Images

✅ What Lambda was designed for:

• Small, lightweight Node.js functions that start up in milliseconds.
• Short-lived execution with minimal dependencies.

❌ Why Docker breaks this:

• Even the most optimized NestJS Docker image is HUGE (~500MB+).
• Lambda pulls the container on every cold start, which can take seconds to minutes.
• Containerized apps have a higher startup time, defeating the purpose of Lambda's serverless scalability.

2. AWS Lambda + Prisma is a Disaster

✅ How a normal NestJS server works:

Runs continuously and stores dependencies on nod_modules.

❌ Why Lambda + Docker makes cold starts worse:

• Every cold start initializes a fresh Docker container (~5–15s startup).
• Lambda must pull the container from AWS ECR, which adds even more latency.
• NestJS bootstrapping is slow because of its dependency injection system.
• If inside a VPC, cold starts can exceed 10–30 seconds (!).

Special point:

The directory where .prisma package goes is kinda unpredictable. For some wierd reason that's the place where my package goes after running prisma generate inside the Dockerfile:

./node_modules/.pnpm/@prisma+client@6.2.1_prisma@6.2.1/node_modules/@prisma/client /app/node_modules/.prisma/client

And i was only able to perceive this because i was echoing the directory where the library went through github actions.

3. AWS Lambda’s Container Runtime Has Many Restrictions
✅ How a regular NestJS Docker container works:

You control everything: OS, networking, environment.

❌ Why Lambda makes this impossible:

• AWS Lambda’s container runtime restricts system calls (you can't run background tasks).
• Filesystem is read-only, so Prisma’s binary caching breaks. Lambda has no long-lived storage unless using EFS (which adds latency and complexity).
• Can’t run extra processes inside the container (e.g., you can't run a worker process in the background).

4. Debugging is a Nightmare

✅ Normal Docker deployments (ECS, Kubernetes) have:

Persistent logs
SSH access to debug issues
❌ Why AWS Lambda with Docker is a black box:

• No real-time debugging (you can only check CloudWatch logs after execution).
• Lambda crashes without logs (Runtime.ExitError with no explanation).
• You need to login into ECS and then access the container, to get the logs inside of it.

TL;DR:

Cold starts kill performance.
Prisma and databases don’t work well in Lambda.
Docker images are too big for Lambda’s fast-scaling model.
Debugging is painful.

If you have huge NestJS app (basically everything is huge on NestJS app's), go for ALB or break it (if possible) in microsservices. Avoid using Prisma or any huge library, you also can't use some cryptography libraries such as bcrypt.