HN Reader

I haven't really followed Next.js and the related ecosystem closely, what does this project do exactly? If I look at Next.js docs [0], they have three options for self-hosting: using a Node server, using a Docker container or as an SPA. Is this project a wrapper around one of those or is it something else entirely? Or to perhaps ask differently, to me it seems you can already self-host Next.js, what's the value add of this specific project?

[0] https://nextjs.org/docs/pages/building-your-application/depl...

Not sure why this is posted as a Show HN. This project has been around for a long time and I don’t think OP is related in any way to it.

I've been surprised by the number of companies adopting nextjs as their defacto framework without concern for the uncomfortable reality that the framework is built to be hosted on vercel with self hosting largely supported as an afterthought. It's great that opennext exists, but it really shouldn't _have_ to exist (as I believe some of the maintainers have publicly stated)

To clarify in the specific case of deploying to cloudflare workers, you can use cloudflares next-on-pages at the expense of a constrained "Edge" runtime.

- https://opennext.js.org/cloudflare#supported-nextjs-runtimes

You don't _need_ opennextjs to _not_ run on Vercel, but it does provide more flexibility than depending on Cloudflare alone (I don't know if there are any tradeoffs to consider as I haven't used it)

If you're new to this stack, I'd recommend taking some time with a toy app to get use to the architecture and frameworks, especially between running locally and deploying to a host. There are some differences that need to be aligned to get it working across all of them, especially when you introduce server actions.

Using Next.js for self hosting is a really bad idea in my opinion (and experience). Despite of what they say (for obvious marketing reasons) their framework is optimized and developed to run on their platform later.

One of the problems people don’t seem to realize, is that when you use it on your own server you are still “paying” for the trade offs they made. Like you will run into artificial limitations that should not be there at all, except because those limitations only help keeping the door open so that you can move into their platform. If they removed those limitations then moving into their platform would be a lot more difficult and obviously they don’t want that.

Do you want proof of that?

https://github.com/vercel/next.js/discussions/46722

Check that whole conversation. It’s now closed with some bullshit because they don’t like people realizing this.

So… if you are using Vercel, then great. Next is your best option for their platform. But using Next outside of vercel is a terrible idea. There are far better options for that.

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?

This in interesting, but while OpenNext is agnostic about the hosting layer, it seems opinionated about the IaC layer. SST is great, but I still use CDK for everything and have no appetite to maintain a snowflake project with a different IaC tool than everything else.

I see that the docs do link to other projects built on top of OpenNext that support other tools, but they seem stagnant and stuck on old versions of OpenNext (which effectively means stuck on old versions of Next.js).

I get that the people behind the project have limited bandwidth, and if they're going to support a tool, they'd first and foremost support the one they use and maintain themselves, but still.

This is great, but my first question is: what is the infrastructure deployed? Is this a cool resume filler, or is it a serious alternative to Vercel? Seeing something around the infra and security in the readme would be great for production grade hosting

Any plans to add support for? https://github.com/awslabs/llrt

It would also be nice to have a V8/deno/bun based edge hosting option that supports the Next.js edge and middleware code splitting instead of using lambda@edge's node setup (which is slow and expensive). That's the missing piece for most homebrew next.js "edge" setups. Production CDNs like Clouflare and Supabase all offer this.

This is very cool.

Do you have any ideal the cost difference of running this VS NextJS for any particular workload?

I use NextJS on Vercel for so many projects but mostly smaller things since I know it can get very expensive after scaling up.

This is awesome! We run Next.js on our own server as we use node-specific APIs in various backend-y places of Next (meaning edge deployment is out) and something like this would definitely help us!

Nextjs has a flaw archtecture fo the ease of starting a project. It will bite u in the long run.

Oooh! I need this. Thanks!