In production, use even number versions like 4 or 6, these are the Long Term Support versions that will be patched for a certain time. These are the versions at which node.js is considered production-ready. The odd number versions are not LTS and you should generally stay away from them if you're worried about production stability.

You should use NVM for managing versions, switching out a version is as easy as a single command, not to mention installing node.js through NVM takes care of every single permissions mumbo-jumbo problem I've ever encountered (global installs, jumbled installs, unhelpful or uncommon errors) and seen people inquire about. After NVM, node stopped being about googling problems and became a smooth experience.

Upgrading node.js should not be very necessary unless your project calls for it (medium to large scale, you have read changelogs and understand some new feature or fix that will benefit you greatly), or you're upgrading to a minor/patch version like from 6.0.0 to 6.2.14 or something (fyi those are not real version numbers). In which case you had better written a comprehensive test suite with 100% coverage so you can make sure things are still functioning after you punch in that aforementioned single NVM command.

If you're later upgrading from 6 to 8 then your tests better have tests ;) /s

In my production environment, I only run LTS NodeJS versions. At the moment, I still use v4, but I am working on the switch to v6.

Since I only write applications for internal use, the servers are not connected to the internet and I have to manually patch node, npm, my applications and their dependencies. But even if the servers had internet access, I would patch them very rarely and carefully. Never touch a running system (if not necessary)!

However, every morning, I check certain tools and blogs for new versions and changelogs and based on the results I decide if an upgrade to a later version is worth the trouble. Some keywords I look for are CVS, Security, Significant Performance Improvement and Bugfix. I usually check if my applications are affected and then do a test-patch on my dev machine. If everything works, I upload the changed environment to the productive systems in a well documented Change process and with the possibility to do a roll-back at any time.