Please note that this describes something you would do for a toy project. If you do this for work you probably want to:
* Install NPM in a way that you can upgrade easily. Your package manager was designed to do this, so use it. Never ever put untracked files in the system directories.
* Don't git clone into production. You need to know which version was deployed when and where. At the very least set a tag. Better yet, roll a package from that tag (see above) which you then can sign and store. It's very easy and there are tools to help.
* Schedule when and how you upgrade your operating system, NPM, and your application. To do this you need a way to take an application out of production, which brings us to...
* You generally want a load balancer or some sort of web server between the world and your application. This could be as simple as an Apache or nginx. Don't muck about with port forwards!
* And most importantly, document this down to every command in the internal wiki! Even better, write a Puppet/Salt/Ansible file and put it under version control.
In short: Tools exist for a reason. Use them. Don't hack files manually until you master the tools and know why they exist.
Exactly my thoughts... this is for toy projects.
It's 2016 and we have proper tools like PM2 [0], StrongPM [1], or even better, Serverless [2] (this is only for AWS but sooo cool) ...