That's how I use Next.js, as a static site generator. Any dynamic stuff goes on top of the static site with a dedicated API server. It makes things so much simpler to not run Next.js in production, other than on client side.
While it's simple to run NextJS as a simple Node process that server-renders everything it's not trivial to run it in the way the Vercel does, including running middlewares specifically on a different edge runtime (as well as supporting the `export const runtime = "edge"` directives); incremental static regeneration (statically pre-rendering some set of routes at build time and then hosting them as static files from a CDN rather than computing them at request time), and so on.
I'm guessing this solution doesn't really do that stuff, but for many apps it's not a big deal if it doesn't.
I've noticed a lot of this lately where someone is like this is an alternative to xyz and it does like 2% of what that service or application actually does.
But why do people online complain so much that Next is difficult to self-host? Is it just because self-hosting is difficult, or is it something about Next? I suppose the fancy stuff such as "skew protection", which is probably going to be quite important for anyone using server components and server actions, is going to be fiendishly difficult to achieve.
Next.js is maintained by a hosting company. While the core framework is open-source, all their solutions to deploy and scale properly are not open-source.
Looks nice for getting things running quickly!
I would advice people not to use this in production yet, though.
E.g. when using the update command, new files in the repo are overridden, but old files aren't removed. https://github.com/alohe/quicky/blob/main/index.js#L878
Next.js export, hosting on Cloudflare pages, and then using Cloudflare workers for any server side stuff is also a great option.
That's how I use Next.js, as a static site generator. Any dynamic stuff goes on top of the static site with a dedicated API server. It makes things so much simpler to not run Next.js in production, other than on client side.
https://webpod.dev works almost the same, but via ssh.
What’s specific about next.js that makes it difficult to host vs a node app?
see - https://opennext.js.org/aws/comparison
Interview with dax from opennext on the topic from a couple days ago:
https://youtu.be/E-w0R-leDMc?si=uzPEd42V_6wxwV9l
and leerob did one a few days before that
https://www.youtube.com/watch?v=sIVL4JMqRfc
nothing specific about next.js but its widely used and this guy chose to provide a easy hands-free tool for that very popular framework
While it's simple to run NextJS as a simple Node process that server-renders everything it's not trivial to run it in the way the Vercel does, including running middlewares specifically on a different edge runtime (as well as supporting the `export const runtime = "edge"` directives); incremental static regeneration (statically pre-rendering some set of routes at build time and then hosting them as static files from a CDN rather than computing them at request time), and so on.
I'm guessing this solution doesn't really do that stuff, but for many apps it's not a big deal if it doesn't.
I've noticed a lot of this lately where someone is like this is an alternative to xyz and it does like 2% of what that service or application actually does.
> nothing specific about next.js
But why do people online complain so much that Next is difficult to self-host? Is it just because self-hosting is difficult, or is it something about Next? I suppose the fancy stuff such as "skew protection", which is probably going to be quite important for anyone using server components and server actions, is going to be fiendishly difficult to achieve.
Next.js is maintained by a hosting company. While the core framework is open-source, all their solutions to deploy and scale properly are not open-source.