nodejs

10 things you should do while running Node.js in production

It’s really easy to develop Node.js application but the real challenge comes when we deploy it. Here is a list of things you should do which I gained by running the various application in production.

PS: These tips are subjective and totally my experience. I had few more but those are specific to projects and I am not sure they will be required for all kind of apps built on Node. I tried to keep these tips as generic as possible.

1: Use reverse proxy

“Listening to port 3000”

I am pretty sure you have come across this common message in your terminal while running Node.js application. This works great in local development because hitting localhost:3000 from a browser is no big deal.

But…What about production? I assume you can’t ask your user to visit your web app by accessing port.

But wait! We can run our app on Port 80 and browser will automatically understand that.

True, but this way you will lose the greatest flexibility and that is running multiple nodejs apps on the same server.

Plus, you will expose your real Port on which your App is running i.e it is directly accessible and open to everyone. This is too risky.

You can avoid all of this by introducing reverse proxy in your setup. This will not only hide the real app configuration but also allows your to run multiple apps on same but on the different port.

Plus you can disallow the port for outside user on which your App is listening and tighten the security.

Nginx is still the king in reverse proxy Server. You can use that, however you can also develop reverse proxy Server in Node.js. We have covered this here.

2: Use monitoring tools

Exceptions happen and Server does crash. Whenever it happens, you should be the one who gets notified, probably not by your Manager but your monitoring tool.

In production, a monitoring tool is your best friend, so choose them wisely. These tools allow you to check the status of your deployment from anywhere, you can check logs, memory usage and get the notification via an email if any exception happens.

Nodejs monitoring using PM2

I personally used two monitoring tools as of now.

  • Keymetrics – by PM2.
  • Trace – by RisingStack

I have covered tutorial on keymetrics, you can learn about it here.

3: Remove console.log statements

We love console.log and why shoud’t we.

It helps us to trace bugs and save our time.

But in production, these statements consumes CPU time and waste the resources. It’s better if you get rid of them in production.

Tip: Use good logging module which contains features such as async log writing, log rotation, and external log storage support. I have used winston module in one app and I can’t complain.

4: Using external store for global store

Storing session ids, sockets ids etc in memory as the temporary store is not gonna work in production because every time you restart your server which could be often in an early stage, you will loose your data. You must use fast external store such as Redis to store such data.

Nodejs and redis

We have covered using Redis as Session store in Node.js here.

5: Use SSL

SSL provides you an extra layer of security by encrypting the data transmission.

Now, most of the time, Nodejs developers reads the SSL key from the file in the Node Server itself, you should always do that using reverse proxy.

Install SSL on reverse proxy and let outside world communicate your Node app via reverse proxy.

6: Recheck security measures

Make sure your app is meeting the security standards. Our fellow developers at RisingStack compiles a list of security check you should consider.

Read the awesome Nodejs security checklist article

Also, always update Nodejs and NPM version to latest one, they contain a lot of security patch and updates.

7: Keep real app only accessible by private users

If your app is running on XYZ.com Server on Port 8080 and it has a reverse proxy, then make sure only reverse proxy Server can communicate to your app, no one else from outside world. This prevents lots of attacks and security loopholes.

Also, restrict the SSH access to the specific network or VPN to prevent the outside access.

8: Run Node.js in cluster mode

Node.js by default do not take advantages of multiple cores of the processor, hence throughput of the system is low if you do not deploy your app in cluster mode.

Node.js clustering

Node.js cluster module allows you to fork multiple child processes of same process. This allows zero downtime and high availaibiilty.

In production, always run your app in cluster mode.

9: Perform more I/O and less CPU intensive task

Always remember, Nodejs runs on single threaded event loop and it is best suited for I/O intensive operation.

Even if I/O operation takes time, Nodejs will serve other requests because of callback nature, however, if your application is taking too much time in performing CPU task such as big calculation etc then Nodejs will be held up the other request and this will in turn slow down the system.

Try to use Node for more I/O operation than processing operation.

10: Use process managers

Running your app with node app.js or gulp etc is fine in development stage. The minute you move to production, you must use process managers to keep your app running forever. These process managers help you to restart your application in case there is an exception.

PM2 application server monitoring

There are npm modules such as forever, pm2 to handle process. We recommend PM2, because of its ease of use and keymetric integration.

Summary

I have covered ten important tips that we should look over during the production deployment. There could be more specific to projects but these ones I found to be general.

Whats your deployment checklist for Nodejs?

What do you do before deploying Nodejs app in production ? Let me know in comments.

Shahid (UnixRoot) Shaikh

Hey there, This is Shahid, an Engineer and Blogger from Bombay. I am also an Author and i wrote a programming book on Sails.js, MVC framework for Node.js.

Related Posts

13 Comments

  1. Very useful article, however I found it amusing to see the ad for “this post was proofread by Grammarly” given that the text of the article is full of grammatical errors.

      1. I like your article. I am just starting to evaluate Node.js and this kind of info. helps me see what it would be like to deploy a real project compared with playing with toy code locally.

        The comment about grammatical errors is right from the POV of a British or US English speaker but Indian English is a little different and no less correct than other dialects when seen from the POV of its users. Some of what people outside India see as mistakes are normal acceptable usage for you.

        There are a few errors by any standard but the comment is unkind and pointless. How many web pages are perfect? How many FREE pages are written by professional writers (requiring payment) putting their copy through professional sub-editors (requiring payment) and a professional editor (requiring payment) to manage, read and sign off?

        This page is FREE, your writing is easy for me to understand and conveys valuable expertise. Mission accomplished and I am grateful.

        Best wishes.

        1. Hi Ian,
          You made my day 🙂
          A response like this motivates us to deliver a free content.
          Regarding grammar, yes you are right, but on the different aspect, I try to write the post as simple as possible because I receive tons of traffic from locations where English is the second language.

      2. I’m not complaining about the author’s English, but about the ad for the grammar checker. Yes, I understand that a non-native American or British speaker will write things differently, and I can accept that. Lots of technical articles on the web don’t have perfect English. But when I then see it immediately followed by an claim that it was proofread by a grammar checker I have to wonder exactly what it’s correcting. What I immediately noticed was misspellings (“loose” instead of “lose”, “shoud’t”, etc.), missing words (“an”, “the”) and other problems. Any decent grammar checker should have caught these.

        If it hadn’t been for the advertisement I wouldn’t have noticed or made any comment about it.

        1. To put it another way: it doesn’t bother me when people make errors, but it bothers me a lot when algorithms do.

        2. Ok, I get your point of view. Regarding the Grammarly which I am using to proofread, I am not sure which algorithm they are running to check grammatical errors and Since I use, it’s best to earn some bucks out of it to keep running this free content blog.

          Regarding grammatical errors, I really don’t care much about them. I am good in English language but I am not a good writer and I never was 🙂 Maybe I will some day…

          Thanks Talin for clarifying.

  2. Shahid,
    I agree with Ian that the comment was mean spirited and unnecessary. You are communicating very well around the world and I have seen more typos on CNBC articles than in yours.

    Keep up the good work.

    1. Agreed. Great information, excellent detail, lots of useful bits that would otherwise not have been available. As a published writer and holder of a Master of Arts degree in English Literature, I state the above with a modest degree of confidence. 🙂

  3. dear Shahid
    Thanks a lot and God bless you.
    this article was very useful and helpful for me. also very informative in brief.
    i found your website the best for those who want to learn node(and its frameworks) and also front-end javascript technologies like angular.
    I decided to follow your web completely. I found it the best between all the web.
    Allah bless you my bro

Leave a Reply

Your email address will not be published. Required fields are marked *