6 ms·

Show HN: Self-Host Next.js in Production

95 points by vednig 2y ago

Onavo 2y ago
Any plans to add support for? https://github.com/awslabs/llrt 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.
- thdxr 2y ago
  llrt is extremely experimental and early - probably not the right fit the latter is being worked on and there is a cloudflare adapter in that github org
  - Onavo 2y ago
    I am aware of the CloudFlare adapter. I am referring to when running as a standard AWS-only SST app.
jonplackett 2y ago
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.
- greyskull 2y ago
  The biggest cost for us on Vercel (several hundred dollars a month) was Image Optimization, and that was because the app was being majorly inefficient with images, in part due to some default behavior in Next.js that we found unfriendly [0], and in part due to negligence. That being said, it wasn't "cheap" by any means outside of that, still hundreds a month for something that I would not consider a high traffic application (I wish I could remember more specific numbers). 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#sizes https://nextjs.org/docs/app/api-reference/components/image#s...
  - syndicatedjelly 2y ago
    That’s insanely expensive for a low traffic web app. Why should anyone use Next.js, given a choice? Are the handful of milliseconds shaved off for the end user worth the cost?
    - jonplackett 2y ago
      People (me at least) us NextJS for the developer experience. It really is quite good. If you mean why use Vercel, again - great developer experience. Just expensive.
    - greyskull 2y ago
      1) I don't think it's related to Next, per se, but there may be behavior I didn't build the expertise to comment on. I also know that there were major inefficiencies in the application, so, for example, our P90 latency was (imo) terrible. 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.
  - dbbk 2y ago
    There's pretty much no reason to use Vercel's image optimization, just spend 30 minutes setting up Cloudflare Images and call it a day
    - greyskull 2y ago
      I agree.
Etheryte 2y ago
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/deploying#self-hosting https://nextjs.org/docs/pages/building-your-application/depl...
- jeremy_k 2y ago
  I believe the intent of OpenNext is to allow you to run your Next.js applications in a serverless manner, same as Vercel.
- taikon 2y ago
  The reason this project is important is because Next.js is hard to deploy if you're not using Vercel to host your app. You can easily run into issues that are hard to resolve. It's creates lock-in with Vercel and is one of the reasons why Vercel has a bad rep.
  - leerob 2y ago
    (I work on Next.js) 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/deploying#self-hosting https://nextjs.org/docs/app/building-your-application/deploy... [2]: https://www.youtube.com/watch?v=sIVL4JMqRfc https://www.youtube.com/watch?v=sIVL4JMqRfc
syndicatedjelly 2y ago
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?
- greyskull 2y ago
  It offers packaging for deploying to a serverless environment (e.g. Lambda) analogous to how Vercel does it. 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.
  - CharlieDigital 2y ago
    How would it compare to running as serverless containers (rather than ECS) like Google Cloud Run or Azure Container Apps (true scale to 0)? It seems like using serverless containers would meet most of the same objectives so I'm not clear where the delineation is here.
    - greyskull 2y ago
      OpenNext does model [0] incremental static regeneration, but beyond that I actually don't know, or at least don't recall. OpenNext doesn't do per-route lambdas like vercel does, so it's not like you get any behavior differences there. I _think_ you can get scale to zero on Lambda by deploying a docker container, too. [0] https://opennext.js.org/aws/v2/advanced/architecture https://opennext.js.org/aws/v2/advanced/architecture
theogravity 2y ago
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!
afro88 2y ago
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
- greyskull 2y ago
  OpenNext is just for packaging the Next.js build artifacts. The infrastructure is defined by projects that deploy those artifacts, examples here: https://opennext.js.org/aws/get_started https://opennext.js.org/aws/get_started 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.
slashnode 2y ago
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)
- threetonesun 2y ago
  Next, as is, works fine self hosted? Certainly not everyone needs serverless functions split out like Vercel does. 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.
  - anonzzzies 2y ago
    > somewhat broken bit of an understatement there
- jmathai 2y ago
  I’m uncomfortable using most JS frameworks. The churn is so high and something new comes out every couple of years. 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.
  - anonzzzies 2y ago
    It is fine to sound like a grumpy old developer. We have clients using nextjs and it might have its place if you have apps in active development with dedicated teams, however for LoB apps for instance that don't change a lot and/or don't have continued dev or a dedicated team over time, it's a bad choice imho. Personally, I consider it a terrible choice always, because of the churn mostly; the current info in SO and LLMs is often wrong because of that churn. Best practices change and you have to pin everything or things auto-break. We get hired for a lot of $ to fix that in emergence settings, but I rather would have that people not use this stuff at all. It's not even a good dev experience imho, but I guess that's personal as either others are resume-devving and lying or just have another idea about what is a nice experience.
hi_hi 2y ago
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 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.
- dbbk 2y ago
  The very link you posted says you can use the Node runtime, you're not limited to Edge runtime.
hysan 2y ago
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.
bilalq 2y ago
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.
revskill 2y ago
Nextjs has a flaw archtecture fo the ease of starting a project. It will bite u in the long run.
rc_kas 2y ago
Oooh! I need this. Thanks!
0xblinq 2y ago
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 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.

95 points by vednig 2y ago

Any plans to add support for? https://github.com/awslabs/llrt 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.

thdxr 2y ago
llrt is extremely experimental and early - probably not the right fit the latter is being worked on and there is a cloudflare adapter in that github org
- Onavo 2y ago
  I am aware of the CloudFlare adapter. I am referring to when running as a standard AWS-only SST app.

jonplackett 2y ago

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.

greyskull 2y ago
The biggest cost for us on Vercel (several hundred dollars a month) was Image Optimization, and that was because the app was being majorly inefficient with images, in part due to some default behavior in Next.js that we found unfriendly [0], and in part due to negligence. That being said, it wasn't "cheap" by any means outside of that, still hundreds a month for something that I would not consider a high traffic application (I wish I could remember more specific numbers). 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#sizes https://nextjs.org/docs/app/api-reference/components/image#s...
- syndicatedjelly 2y ago
  That’s insanely expensive for a low traffic web app. Why should anyone use Next.js, given a choice? Are the handful of milliseconds shaved off for the end user worth the cost?
  - jonplackett 2y ago
    People (me at least) us NextJS for the developer experience. It really is quite good. If you mean why use Vercel, again - great developer experience. Just expensive.
  - greyskull 2y ago
    1) I don't think it's related to Next, per se, but there may be behavior I didn't build the expertise to comment on. I also know that there were major inefficiencies in the application, so, for example, our P90 latency was (imo) terrible. 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.
- dbbk 2y ago
  There's pretty much no reason to use Vercel's image optimization, just spend 30 minutes setting up Cloudflare Images and call it a day
  - greyskull 2y ago
    I agree.

Etheryte 2y ago

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/deploying#self-hosting https://nextjs.org/docs/pages/building-your-application/depl...

jeremy_k 2y ago
I believe the intent of OpenNext is to allow you to run your Next.js applications in a serverless manner, same as Vercel.
taikon 2y ago
The reason this project is important is because Next.js is hard to deploy if you're not using Vercel to host your app. You can easily run into issues that are hard to resolve. It's creates lock-in with Vercel and is one of the reasons why Vercel has a bad rep.
- leerob 2y ago
  (I work on Next.js) 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/deploying#self-hosting https://nextjs.org/docs/app/building-your-application/deploy... [2]: https://www.youtube.com/watch?v=sIVL4JMqRfc https://www.youtube.com/watch?v=sIVL4JMqRfc

syndicatedjelly 2y ago

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?

greyskull 2y ago
It offers packaging for deploying to a serverless environment (e.g. Lambda) analogous to how Vercel does it. 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.
- CharlieDigital 2y ago
  How would it compare to running as serverless containers (rather than ECS) like Google Cloud Run or Azure Container Apps (true scale to 0)? It seems like using serverless containers would meet most of the same objectives so I'm not clear where the delineation is here.
  - greyskull 2y ago
    OpenNext does model [0] incremental static regeneration, but beyond that I actually don't know, or at least don't recall. OpenNext doesn't do per-route lambdas like vercel does, so it's not like you get any behavior differences there. I _think_ you can get scale to zero on Lambda by deploying a docker container, too. [0] https://opennext.js.org/aws/v2/advanced/architecture https://opennext.js.org/aws/v2/advanced/architecture

theogravity 2y ago

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!

afro88 2y ago

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

greyskull 2y ago
OpenNext is just for packaging the Next.js build artifacts. The infrastructure is defined by projects that deploy those artifacts, examples here: https://opennext.js.org/aws/get_started https://opennext.js.org/aws/get_started 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.

slashnode 2y ago

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)

threetonesun 2y ago
Next, as is, works fine self hosted? Certainly not everyone needs serverless functions split out like Vercel does. 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.
- anonzzzies 2y ago
  > somewhat broken bit of an understatement there
jmathai 2y ago
I’m uncomfortable using most JS frameworks. The churn is so high and something new comes out every couple of years. 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.
- anonzzzies 2y ago
  It is fine to sound like a grumpy old developer. We have clients using nextjs and it might have its place if you have apps in active development with dedicated teams, however for LoB apps for instance that don't change a lot and/or don't have continued dev or a dedicated team over time, it's a bad choice imho. Personally, I consider it a terrible choice always, because of the churn mostly; the current info in SO and LLMs is often wrong because of that churn. Best practices change and you have to pin everything or things auto-break. We get hired for a lot of $ to fix that in emergence settings, but I rather would have that people not use this stuff at all. It's not even a good dev experience imho, but I guess that's personal as either others are resume-devving and lying or just have another idea about what is a nice experience.

hi_hi 2y ago

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 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.

dbbk 2y ago
The very link you posted says you can use the Node runtime, you're not limited to Edge runtime.

hysan 2y ago

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.

bilalq 2y ago

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.

revskill 2y ago

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

rc_kas 2y ago

Oooh! I need this. Thanks!

0xblinq 2y ago

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 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.