Deploying a production Node.js server [closed]

Answer 1

See Hosting Node Apps.

This tutorial walks you through setting up a server that can host node.js apps for server-side JavaScript applications. Right now, the node.js hosting options boil down to running node daemon processes that talk to a web server. Most web servers can proxy connections to a different port, so you’ll be able to use Apache or nginx to do this.

Answer 2

There are three questions here, I think.

Question 0: "Should I use a framework for my node app?"

Question 1: "How do I run node servers on production machines?"

Question 2: "How do I deploy node apps to production".

For Question 1, I really like Cluster (although the latest Node version has something like that built in, so you might check that out). I've had good success with something like Monit/Upstart to monitor OS level events and make sure your servers are in good health. (This was monitoring N clusters of Ruby Thin servers, but same thing).

Depending on the traffic you may want to run cluster on multiple machines, then putting a load balancer in front of that. This depends on your traffic, how long requests take to complete / how long you block the event loop, and how many processors/node instances you launch per machine.

A framework gives you better error handling, and catches errors that would exit normal node.js apps. If you do it without a framework, make sure you read up on error handling in node.js.

For Question 2, I don't think the node community has a good deploy standard yet. You could try using Ruby's Capistrano tool (and here's a blog entry talking about deploying cluster with Capinstrano).

The bad thing about Capistrano is that it makes some assumptions that might not be true (ie: that you're deploying a Rails project), so you may end up fighting with the framework a lot.

My goto deployment solution in general is Python's Fabric tool, which gives you deployment tools and lets you do what you need to do.

Another deployment option is "the cloud", with things like Nodester: let them take care of it.

Answer 3

Try using pm2 it is simple and intuitive CLI, installable via NPM. Just start your application with PM2 and your application is ready to handle a ton of traffic

PM2 Offical Link

How to set up a node js application for production using pm2

Answer 4

The guys at Cloudkick wrote an an excellent solution to this. It's called Cast, http://cast-project.org/.

Install cast on your server and on your workstation. You start the cast-agent on the server and have your workstation sign with the servers cast instance. You can then create "bundles", upload them to the server, create/upgrade/destroy from them as well as start/stop the your instances. Cast will automatically restart your services when they crash. You can also tail the stdout/strerr remotely as well as get a list of running instances and PID#s and manage your instances/servers from your workstation (no SSHing required). The docs are slightly out of date, but the results are worth the little bit of extra work. All of the interactions/commands are over HTTPS and a RESTful API.

Prior to this I was doing all the upgrades by hand with SCP/SSH. We has supervise keeping things up. We haven't looked back.

Answer 5

• You should really really use a framework (I recommend something like Express since it was battle-tested) unless you want to deal with sessions, cookies, middleware etc by yourself. Express is really light.
• Starting the server with nohup: you shouldn't do that, just start it with the regular "node" command. Also Express wraps the routes in a try-catch, so your server won't crash in a route. However if your server does have a serious problem, you shouldn't fear restarting it (besides, if you have 2-3 processes at least, only one will die, so there will be at least 1-2 remaining and the user won't feel a thing).
• For monitoring I personally prefer something more at the OS-level such as Upstart and Monit.
• Hosting solution: since you already have your own serious hardware stuff, no need to invest money in something else. Just use a load-balancer (maybe nginx or node-http-proxy) to proxy stuff.

Answer 6

You might get better answers over on ServerFault, but there's a description of one user's experience here using supervisord. You're going to need to use some sort of process watcher to keep the node process alive, and another common recommendation seems to be to reverse-proxy connections to the node process somehow. I'd probably vote for nginx (this way you can have nginx handle the logging, authentication, or any other higher-level HTTP features you need as opposed to somehow baking them into node), but the aforementioned article mentions haproxy in the comments here and there which may be more lightweight. Your choice of reverse-proxy will probably depend largely on whether or not you need WebSocket support.

I'm not sure any more "standard" workflow exists for node just yet; it's not quite as mature as something like Rails that has a myriad of ways to keep a webapp running.