Leaving this here in case someone can use it as a jumping off point, but the copying method used breaks at scale. Ends up being a race between the first container and when the others start up, and they can break one another. Recommend a different strategy.
Have a very simple use case for Next.js? Perhaps akin to what you would use a SPA (single page app) for? Check out cdk-nextjs-export-s3-dynamic-routing.
Deploy a Next.js site to AWS ECS supporting all version 13 features, including properly functioning, efficient Incremental Static Regeneration and Image Optimization.
This construct employs AWS EFS to share the .next directory between containers, as is recommended by Vercel.
A full example including custom domain, SSL, and Cloudfront is in the /example folder. This construct can also be used with only a VPC and ALB as well, with no caching or custom domain.
You can see the requirements for this construct there, but they are also spelled out in detail below.
The full API of this construct is available in the API.md file.
outputmust be set tostandalone. This is what Vercel recommends for Docker based deployments.experimental.isrMemoryCacheSizemust be set to zero. Without this, you can get odd responses when using ISR and having multiple containers.
Some minimal scripts that handle moving files around when a new build is created are required. They are available in the docker folder.
The following should be inserted during the final steps, just after the standalone folder is copied.
# Additions from NextjsStandaloneEcsSite
# We use curl to run the health check on the container
RUN apk add --update curl
# Copy our scripts to the root of the container
COPY --from=builder --chown=nextjs:nodejs app/docker ./
# Move the build out of the way of our .next folder shared across containers
RUN mv ./.next ./.next.currentBuild
RUN mkdir -p ./.next
RUN chown nextjs:nodejs ./.next
# End additions from NextjsStandaloneEcsSite
In addition, the final line in the Dockerfile should be changed to:
ENTRYPOINT ["sh","./startup.sh"]
Instead of any CMD or existing ENTRYPOINT. You can add to startup.sh if you need to run additional commands before the container starts.