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.

> Please note that this describes something you would do for a toy project.

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) ...

[0] https://github.com/Unitech/pm2

[1] http://strong-pm.io/

[2] https://github.com/serverless/serverless