How should a Node.js server be started in production?

realsenorloadenstein 0
Viewed 21

In my Node.js server I'm using app.listen(443); to try and listen and use HTTPS. This gives me the following error when I try and run it on my Linux server:

  Emitted 'error' event on Server instance at:
  at emitErrorNT (node:net:1459:8)
  at processTicksAndRejections (node:internal/process/task_queues:83:21) {
  code: 'EACCES',
  errno: -13,
  syscall: 'listen',
  address: '0.0.0.0',
  port: 443
}

I have no idea what this means, but it seems like the server is having an issue using port 443. Did I do something wrong when I started the server with app.listen()?

port linux https server node.js
1 Answers

Ports under 1024 require extra extra access to open. Your application isn't running as root (that's good!) so it doesn't have access to listen on 443.

Depending on your linux distribution, there are a variety of ways to allow a particular user access to a particuar port.

My advice? Don't use any of them.

how should a ... server be started in production?

With a tried and trusted reverse proxy / load balancer fronting the application. nginx, haproxy, and apache are 3 examples of load balancing / reverse proxy software that can listen on 443 with your appropriate SSL certificate and forward requests down to your application on some port above 443.

There's a number of reasons to do this:

  • Hardening. these applications are expressly built to handle high volumes, bad actors, network issues. They're capable of handling high volumes of traffic with comparatively few resources.
  • Flexibility and availability. If your application runs on 443, the only way to upgrade the app is to first stop the old version. Then you can start the new version on the same port. In the mean time, until new version is ready to serve requests, your application is offline. If application port is irrelevant and behind load balancer, you can bring up new version along side old. You can even slowly cut over traffic by percentage, giving you a chance to "switch back" if you don't like the look of your SLIs (service level indicators - ie metrics that tell you whether your application is functioning properly and users are successfully using)
  • Scalability. So when you need to add another server, it's no big deal at all. Or maybe this should be under "availability" because being able to replace servers is way easier than upgrading and maintaining them at the end of the day.

If you're on a cloud provider, they can offer load balancers. at $20 or so a month they tend to be a bit expensive for ultra low budget, low volume applications (which are better suited to serverless architectures anyway). Otherwise, it's well worth the money to have a consistent, reliable, well logged, and fully managed load balancer in front of your apps. (intereseting aside: at least on amazon, and likely on other providers, you can use one load balancer to host multiple different applications and distinguish based on hostname or other attributes of the request. You can also send requests to a lambda functions, which can provide significant monetary savings compared to running a dedicated operating system, not to mention the time you save not having to manage the OS).

erik2580
Related