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.
That puts it at the same level as every other framework, who is not owned by a hosting company and doesn't even have an official solution to scale and deploy "properly"
I've had some issues with caching and some load balancing but was only testing it out. What frustrated me most was when you ask anyone for advice they just say "use docker" missing the whole point of self hosting.
Why does self-hosting mean not using docker. Some people don't like overhead, but that's not the point. The point is to control your own stack and docker can make it more managable.
If you dont like docker I guess just copy the script in the Dockerfile?
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.
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.
That puts it at the same level as every other framework, who is not owned by a hosting company and doesn't even have an official solution to scale and deploy "properly"
I've had some issues with caching and some load balancing but was only testing it out. What frustrated me most was when you ask anyone for advice they just say "use docker" missing the whole point of self hosting.
Why does self-hosting mean not using docker. Some people don't like overhead, but that's not the point. The point is to control your own stack and docker can make it more managable.
If you dont like docker I guess just copy the script in the Dockerfile?
https://webpod.dev works almost the same, but via ssh.
[flagged]