Show HN: Self-Host Next.js in Production
github.com
github.com
[0] https://nextjs.org/docs/pages/building-your-application/depl...
The OpenNext project serves two purposes. First, it was to document some of the quirks when self-hosting Next.js. As of Next.js 15, the majority of these have been fixed, thanks to their feedback. The second is to provide an adapter for serverless Next.js deployments, similar to Vercel. Their adapter takes the Next.js output and transforms it to work in a serverless environment.
We're working with the maintainers of OpenNext to patch up some of the remaining quirks for deploying Next.js serverless and exploring how to make the maintenance of these community adapters easier.
If you want to self-host Next.js on a server, like a VPS or Node.js server, all features of Next.js are supported[1] and you do not need to use OpenNext. Our self-hosting docs include 10 example repos for deploying to different providers and a video walking through all features and options of Next[2].
[1]: https://nextjs.org/docs/app/building-your-application/deploy... [2]: https://www.youtube.com/watch?v=sIVL4JMqRfc
I want to +1 that Vercel has been really improving their portability. We still have Next.js specific code in Firebase, and having different architectures can sometimes make us have to figure out the best mapping of their features, but Vercel has made a noted effort to improve encapsulation of Vercel-specific features and portability has improved. I’m honestly surprised that OpenNext, which is not a new project, seems to have gained a lot of attention in the immediate past.
As other commenters have touched on - my understanding is the purpose of OpenNext is to package the output artifacts of a Next build in a way that can be deployed to a serverless environment, analogous to how Vercel does it. The supporting projects like SST and the other links in the repo are to take those OpenNext artifacts and deploy them to infrastructure generally in an opinionated way - additionally supporting some of the "extra" features described in the repository.
The last project I was working on was to then migrate from SST to Fargate, as a persistent process (serverful?) deployment was preferable for various reasons. In that scenario, we would just be running the built in server using the Next.js standalone deployment mode (effectively a `node index.js`). We didn't need the extra functionality covered by OpenNext.
To Remix?
Btw, remix itself is deprecated. There you go.
What would I use? For sure I’d go with a MUCH saner and stable approach: inertia.js as the glue between React and a real full stack batteries included framework such as Adonis, Laravel or Rails.
At the risk of sounding like a grumpy old developer, I am currently using minimal JS, native when possible and jquery as needed. The UX is just fine. Some pages have interactive JS but most reload the page. I have a hard time imagining this isn’t an option for most web apps.
I’m more surprised because it often feels like Next is slowly rediscovering the last 20 years of web frameworks in janky, somewhat broken steps.
bit of an understatement there
- 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.
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.
The last question is salient, and it's possible for OpenNext to break and have to catch up to changes in Next.js, though I believe there's some more direct collaboration. I'd say that's the biggest downside - it's not guaranteed compatibility.
I did a migration recently (comments elsewhere in this post), and I don't recall the specific issue, but I _do_ recall running into at least one scenario where OpenNext had made a decision that impacted - in a way that was visible to me and undesirable - how Next.js functioned. That's not a criticism, there's tradeoffs.
It seems like using serverless containers would meet most of the same objectives so I'm not clear where the delineation is here.
I _think_ you can get scale to zero on Lambda by deploying a docker container, too.
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.
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.
the latter is being worked on and there is a cloudflare adapter in that github org
Some of them are, for example, Terraform projects that list the specific infra. I have experience with the SST deployment, whose website unfortunately doesn't do a great job of listing the infra architecture.
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.
Migrating to OpenNext using SST, I think we got the bills for compute and asset serving down to like $15/day or something (granted, we spent expensive engineer time on the migration).
[0] https://nextjs.org/docs/app/api-reference/components/image#s...
2) We'd have to define what constitutes low traffic vs any other arbitrary measure, so it's moot to discuss like this; all I said it wasn't high traffic. You could run it for cheaper, but there wasn't much expertise for self-hosting, for example.
3) For all I remember it may have been half that in daily cost. In any case, miniscule compared to engineer time. What was worse was the prior decision to use serverless aurora rds, that dwarfed everything else in AWS cost - I know this is tangentially related, just saying optimizing that a bit more was not the highest priority, we could do it for cheaper.