primo VS serverless-next.js

> Why is are all static site generators (that I am aware of) are CLI? What prevent simplistic drag and drop GUI/WYSIWYG that generates those clean static files?

Check:

- Tina CMS: https://tina.io/

- Primo CMS: https://primocms.org/

Anyway, you seem to be holding the wrong end of the stick. Static generation is the easy part, what you're looking for is a subset that falls under the CMS umbrella, just search for `CMS+SSG` you'll find a diverse set of solutions.

You can also setup any generic Headless CMS to trigger generation for a static site. Why would someone build a full fledged CMS and limit it to a niche market inside a niche?

The easiest thing would probably be Primo, you’ll just have to copy+paste your code in & write some Svelte to set up the content fields.

Check out Primo - it would let you hand the site off to a client so they could edit it & publish changes themselves and just rope you back in to make code updates

Check out Primo - it’s free & open source and they’ll be able to edit it afterwards easily.

Check out Primo it’s FOSS & easy for nontechnical content editors, but you won’t be able to use Hugo with it

Check out [Primo](https://primocms.org)

I'm currently waiting SST v2 to be released where they will use https://open-next.js.org instead of https://github.com/serverless-nextjs/serverless-next.js

To deploy the app, I had the requirement to use AWS as a cloud-provider, with a limited budget, so neither Vercel (a safe choice, as it is the company which develops Next.js), nor a containerized solution like the managed AWS ECS Fargate service could satisfy my needs. Then, I started with a serverless hosting thanks to the serverless-next project, which provides a serverless plugin or a CDK construct to deploy a Next.js stack. However, this project is no more well-maintained and new Next.js features (like middlewares, etc.) are not supported.

If you have the time and resources, I'd suggest to take a look at SST.dev and or OpenNext (created by the SST people). With that ISR should work (although they still seem to work on upgrading to v12). Or take a look at https://github.com/sladg/nextjs-lambda to run NextJS on a lambda exclusively.

serverlessnextjs does not support NextJS 13. https://github.com/serverless-nextjs/serverless-next.js/issues/2497

I hate Amplify. I've been using it for around 2 weeks, because serverless-next.js no longer works with Next v13.

Let's mention that it's possible to deploy a Next.js application using SST 😅. This setup relies on the serverless-next.js project and it's hidden behind a construct named NextJsSite. It can be a very efficient solution when you want to ship your application on AWS environment (I use it for a production workload in my current company).

ATM Next JS is SSR (Server Side Rendering) so only S3 and CloudFront is not enough! As mentioned here already Lambda@Edge can do the server parts and is used like in Amplify. An Alternative would the serverless framework which offers a next js deployment https://github.com/serverless-nextjs/serverless-next.js .