Comment by syndicatedjelly
16 hours ago
What does this offer, that a Dockerized Next.js application running on ECS doesn’t? What are the downsides to using this? Does it stay up-to-date with Next.js, or is there slippage as the maintainers of this project keep up with new updates to Next.js?
It offers packaging for deploying to a serverless environment (e.g. Lambda) analogous to how Vercel does it.
The last question is salient, and it's possible for OpenNext to break and have to catch up to changes in Next.js, though I believe there's some more direct collaboration. I'd say that's the biggest downside - it's not guaranteed compatibility.
I did a migration recently (comments elsewhere in this post), and I don't recall the specific issue, but I _do_ recall running into at least one scenario where OpenNext had made a decision that impacted - in a way that was visible to me and undesirable - how Next.js functioned. That's not a criticism, there's tradeoffs.
How would it compare to running as serverless containers (rather than ECS) like Google Cloud Run or Azure Container Apps (true scale to 0)?
It seems like using serverless containers would meet most of the same objectives so I'm not clear where the delineation is here.
OpenNext does model [0] incremental static regeneration, but beyond that I actually don't know, or at least don't recall. OpenNext doesn't do per-route lambdas like vercel does, so it's not like you get any behavior differences there.
I _think_ you can get scale to zero on Lambda by deploying a docker container, too.
[0] https://opennext.js.org/aws/v2/advanced/architecture