n8n fails to initialize on Kubernetes when configured to use privileged port 80 via Helm

Based on your description, it appears the workflow hangs when you change the port to 80, without even logging an error. A common culprit in this scenario is that port 80 is a privileged port. In most container images (including those for n8n), the process runs as a non-root user, and binding to ports below 1024 (like port 80) requires elevated privileges.

Some points to consider:

• Privileged Ports: Ports below 1024 are reserved for privileged processes. If the container is running as a non-root user (which is common for security reasons), it won’t have permission to bind to port 80.
• No Error Logs: The lack of an error message in the logs might indicate that the application simply hangs waiting for a successful bind or the OS silently drops the request.
• Best Practice: It is generally recommended to run n8n on its default port (5678) or on a non-privileged port. If you must serve on port 80 (for instance, to serve traffic externally), consider using a reverse proxy or ingress controller in your Kubernetes setup to map port 80 to the internal non-privileged port.
• Alternative Approach: If you really need n8n to bind directly to port 80, you might configure the container to run as the root user or adjust capabilities, but this approach raises security concerns.

In summary, it’s likely that running on port 80 is causing a permission issue, preventing n8n from initializing properly. The recommended solution is to leave the application bound to a non-privileged port and handle the port mapping externally (e.g., via an Ingress in Kubernetes).