Fix: Allow users to specify a bind address for self-hosted Next.js applications #77612
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
What?
This change adds the ability for users to specify a bind address for self-hosted Next.js apps. By default, if a hostname is set, Next.js will bind to the hostname's loopback address. This becomes problematic within a Kubernetes environment.
Why?
When self-hosting a Next.js application on Kubernetes, it will automatically listen on the pod's private IP address. This causes an issue with Kubernetes port-forwarding, it's not possible to forward requests to the Next.js container. For example, attempting to port-forward to a container will result in the following error:
A workaround for this is to either set the HOSTNAME to an empty string in the Dockerfile or in the Kubernetes deployment.
How?
Allowing the user to specify the bind address provides a cleaner approach to this problem. The pod retains its hostname, and the user can configure Next.js to listen on all interfaces within a Kubernetes environment. This is useful when a user wants to troubleshoot an issue without having to setup an ingress controller.