I'm trying to deploy a nodejs application to google cloud, I've posted several SO questions about the errors I've been getting and how to fix them. Let me illustrate my endeavours...
problem 1) I tried following the tutorial, the hello world app deployment. When I entered the command to deploy,
$ gcloud preview app deploy app.yaml --set-default
It gave me an error saying managed vms aren't available for your application's region. I contacted someone from Google, a technical support representative from google, said his name was Ling, and he said he "wasn't aware managed vms weren't supported in India" and he wanted me to point out where I found that information. So I sent him this, note one of the answers. OK.....
problem 2) So, I was stuck, didn't really know what to do. Searched "how to deploy nodejs app on google cloud" and found a video in which a google developer informed me that there are "two main ways to run your application in the cloud, infrastructure as a service and platform as a service". Running it on app engine was the platform as a service, and that was off the list so I went with my only remaining option. There is a tutorial, the bookshelf app tutorial, also by google, and the last part describes how to run your application on the compute engine. I tried to go through the tutorial, but when I entered the command
git push cloud 7-gce:master
to push my code to the repository, it's asking me for my username and password, It never mentioned that in the tutorial, I don't know what to enter. I found this question but I'm not sure it applies to my situation. So next I went through some tutorials suggested by Zachary Newman, and I wasn't able to follow the tutorial where they use the ubuntu because when they tell you to hello.js file, it's really weird because I had to ssh into the ubuntu image vm I created and everything was really slow, I'm not familiar with commands on linux so I had to look up how to "save and exit" after creating the hello.js file. I got the "web server" to run, it's the reverse proxy nginx server, but since I don't know what the APP_PRIVATE_IP_ADDRESS is, when I accessed the page, I could see the nginx page but not the "hello world" message that's supposed to display. Please see the Prerequisites heading to see what the tutorial was trying to teach me. OK....
problem 3) On the google developers console, once you log in, there is a navigation section on the left, there is a link to the "Cloud Launcher". In there I found a link to create a Virtual Machine with nodejs installed, it's created by Bitnami. I clicked it and my vm was running, I went to the external ip address provided, and saw a Congratulations (ugh...) page by Bitnami. I didn't really know what to do from there, so I posted another SO question. A bitnami developer told me I "need to copy your files to the remote repository, create the configuration files and after that you have to include that configuration in the configuration of Apache to serve the application". How?!?! He just posted a link as well to a bitnami wiki page. I used filezilla to connect to my vm, and I tried to upload my application files to the vm. I was able to upload everything except the node modules (they were taking too long to upload and for some reason the ftp client kept loosing the connection with the server after 10 minutes or so of uploading). So I thought I would just ssh into the instance and try to npm install my dependencies. But it gave me more errors...
problem 4) I don't know why this post was put on hold, but I found this. I can't find the exact page right now but I read somewhere in the google docs that we can't ssh into an instance as root/administrator by design, and that we have to perform some advanced configuration in order to be able to do this. THE PROBLEM is that I can't install the dependencies unless I ssh in as an administrator....:'( So I just uploaded my node modules with filezilla. Everything looks good to go, I ssh into my instance and I cd into my application directory and enter the command
node app.js
and almost as if to taunt me, it console logs out "connected to mongo...." and "Listening on port 3000.....". I get so excited, I think it's working.....
problem 4) The server never really started running I think, it wasn't able to connect to the mongodb database (another instance) that I was running, this was the command to connect to the mongodb instance in my app.js file
mongoose.connect('mongodb://****/myappdatabase');
where the **** indicates the external IP of my mongodb instances. After about 5 minutes, I get an error on the ssh browser
Error: connect ETIMEDOUT ****:27017
BUT WHO HAS TIME TO READ ALL OF THIS RIGHT?
I'm not a developer, I don't have much experience with programming (close to zero actually). I'm a hobbyist. I picked up a book on c programming by stephen g. kochan about 5 or 6 months ago, and since then, I've just been following tutorials on the internet, a programming in java book, and some reference material. I wanted to create a website.
I learned some html, css, javascript and jquery off of w3schools and went through some tutorials on creating a basic node server and serving some html pages, that's literally all my application does. That's all I want it to do.
I used the express framework for node, and mongoose to connect to my mongodb running locally. Socket.io for a little bit of networking. I created the website for fun and I would really like to host it and share it with my friends, I made it this far, it would be really embarrassing to quit now because I can't host the website. I went through a lot more than what I posted on this question by the way.
Now I would really appreciate some help, even some guidance as to what I need to know, maybe books I should read or documentation I should go through to become more familiar with website hosting would be great. I am going to offer this question up for a bounty in 2 days but until then, if there is anyone that went through this and would like to help for no personal gain of their own, your saving my life. I've been going at this for about 4 days with no luck. Thanks and let me know if there is anything you would like to know about my application. I mean seriously, how hard could it be, I'm doing something (or everything) terribly wrong.
Wow dude. I thought about flagging this, but you appear to genuinely want to learn to program and need help. And experienced coders teaching novice coders is what this site is all about. So, here we go.
First and foremost, Linux is your friend. Learn it. Use it. I don’t use Ubuntu, but you should. Use 14.04 because it’s a forgiving disto and comes cram-packed with things you need when you’re just learning.
Time to address your questions:
Problem 1: you are using a gcloud preview product. Those are awesome, but not for beginners because you don’t know what you’re doing. Just stand up an Ubuntu instance on an n1-standard and rock it. No bells. No whistles. Learn Ubuntu linux with the same passion that you taught yourself how to program a web site.
Problem 2: Don’t use git. I use git every day and it’s awesome, but you have a long way to go and git is hella confusing. Take your workspace, tar/gzip it and just ssh the whole shebang to cloud. Then unzip it and you’ll have your whole code right there on your server. Caveat: never do this professionally. But for someone just learning … small bites dude … small bites.
Problem 3: Don’t use Bitnami pre-built images. It robs you of the opportunity learning how to do this from scratch and that is an invaluable experience. Here are two commands you must learn:
apt-get update
apt-get install <insert thing you want to install>
That’s it. Not rocket science and you will discover the power of package management on linux.
Problem 4: You are over-thinking this. For real, learn apt-get. It will get you so far, you’ll curse yourself for not using it earlier. apt-get node. apt-get mongo. And slam it all on one instance. Is that what I do professionally? Hell no. But it’s all about baby steps when you combine dev-ops with programming and you need to take those steps.
Errata: You wanted someone to recommend a book or a website or guidance. All you need to know is already on Ubuntu. They are called man pages. It’s short for manual. You can buy all the books in the world off Amazon and watch infinite youtube pages. It won’t compare to simply maning commands. You gotta trust me on this.
In summary: Just create an Ubuntu instance. tar and gzip all your code and scp it to your instance. Learn apt-get and for real, you are set. You will totally destroy your instance many times. So just delete it, re-create it, and keep starting over. Each time, you will be wiser and smarter than the time before. I tutor novice developers all the time. You gotta start small and work your way up. Eventually you’ll understand why you’d want to use git. Why you want to scale. Why LXC is amazing. Why GCE’s managed instance and VMs are crazy baller, and why scripting your deployment is a best practice. But first you have to understand how to build an instance and get your code there in any way possible. You’ll grow from there. Good luck, buddy.
Related
I am playing with node.js and angular for first time. I use shared server hosting space. I am trying to get some node.js tests running.
CPanel seem to provide interface to deploy node applications. Example:
application url: myurl.com
application root: node-hello-world
application startup file: app.js
This seems to create directory and some artifacts in
/home/myurl/nodevenv/node-hello-world/6/bin
I have (limited?) shell access through Cpanel emulation, however I get error on source command.
source activate
got error: error: jailshell: fork: Cannot allocate memory
Does this mean node.js is installed and ready to run? Do I have to upload project as well? Where to? Trying to find more info on process of deploying to this type of server if possible.
sorry for nooby question.
Googling your error message, I came across this thread -- which admittedly is very old, but it's from cPanel and has the following comment from an administrator at the time:
Jailshell is a constrained environment by design. It is not meant to be a replacement for a full-featured, unrestricted, shell environment, such as is provided by Bash. If your user's need such full-featured environments then perhaps they need full shell access, or another method whereby they can accomplish their goal.
That answer was given in 2006 (yes, 13 years ago) but I have to imagine the spirit of that response is still true.
To be perfectly honest, I'd be afraid to use any shared hosting provider that would give you more than very limited shell to use -- it opens the door to many security vulnerabilities, and if multiple customers are in the same runtime (i.e. shared hosting) it could be catastrophic. Maybe your host does allow this, or maybe what you're describing isn't actually the same thing I'm referring to... you didn't offer a lot of details on this point.
Back to your question: Does this mean node.js is installed and ready to run? Do I have to upload project as well? Where to?
If I had to guess, Node probably isn't installed (it isn't in most shared hosting providers) -- but I can't say for sure based on the information you provided. My recommendation would be to call their customer support. Or pay for a dedicated hosting account where you get root access. Or just use something like Heroku.
I'm moving my Three.js app and its customized node.js environment, which I've been running on my local machine to Google Cloud. I want to test things out there, and hopefully soon get some early alpha testing going with other people.
I'm not sure which is the wiser way to go... to upload the repo I've been running locally as-is onto a VM which users would then access via the VM's external IP until I get a good name to call this app... or merge my local node.js environment with what's available via the Google App Engine and run it on GAE.
Issues I'm running into with the linux VM approach... I'm not sure how to do the equivalent on the VM of what I've been doing locally. In Windows Powershell I cd into the app directory and then enter node index.js. I'm assuming by this method of deployment that I can get the app running as soon as the browser hits the external IP. I should mention too that the app will allow users to save content as well as upload images, and eventually, 3D models as well as json datasets.
Issues I'm running into with the App Engine approach: it looks like I only have access to a linux-based command line, and have to install all the node.js modules manually. Meanwhile I have a bunch of files to upload, both the server-side node files and all the frontend stuff. I don't see where to upload those files, and ultimately what I'd like to do is have access to a visual, editable file-tree interface, as I have in Windows and FileZilla, so I can swap files in and out, etc. Alternatively I suppose I could import a repo from Github? Github would be fine as long as I can visually see what's happening. Is there a visual interface for file structure available in GAE somewhere? Am I missing something?
I went through the GAE "Hello World" tutorial and that worked fine, but was left scratching my head afterward regarding how to actually see and edit the guts of the tutorial app, or even where to look for the files.
So first off, I want to determine what's the better approach, and then if possible, determine how to make the experience of getting my app up there and running a more visual, user-friendly experience.
Thanks.
There are many things to consider when choosing how to run an app, but my instinct for your use case is to simply use a VM on GCE. The most compelling reason for this is that it's the most similar thing to what you have now. You can SSH into the machine and run nohup node index.js & (or node index.js inside tmux/screen if you prefer) and it will start the app and not stop it when you log out of SSH. You can use SCP / SFTP with whatever GUI client you want to upload files. You don't have to learn anything new! If you wanted to, you could even use a Windows VM (although I think you have to pay a little more than for a comparable Linux VM due to the licensing fees).
That said, the other way is arguably more "correct" by modern development standards, but it will involve a lot more learning that will prevent you from getting your app running somewhere other than your laptop in the short term:
First, you'll need to learn about Docker and stateless containers, which is basically what your app runs inside of on AppEngine.
Next, you'll need to learn how to hook up a separate stateful service (database, file server, ...) to your app's container so you can store your files, etc. in it, and then probably rewrite your app somewhat to use it to store stuff.
Next, you'll probably want some way to automatically deploy this from code instead of manually doing it, which gets you into build systems, package managers, artifact storage, continuous integration systems, and on and on and on.
This latter path is certainly what you should choose for a long-running production service if you work with a big team of developers -- but that doesn't mean that it's necessarily the right path for your project today. If you don't care about scaling up automatically, load balancing between nodes, redundant copies of your app running in different regions in case there's a natural disaster, etc., then go with the easy way for now, and you can learn new ways to improve the service when they're actually needed.
I've built an application that run with node.js, which permit to retrieve some data through a REST API.
I want to put it online on a personal computer (Windows), but I have no idea how to install a server and what I need to make my application available online.
Can someone explain me the steps to do it ? I know that some online services exists like Heroku but I want to do it by myself.
Thank you
This question looks small, but it's actually huge. I started writing this as a basic guide, and it ended up really being quite a lengthy answer, so I split it into pieces. Overall hope this helps!
Using a VPS
You don't want to serve a website from your personal computer, because any time your computer is off, the website will be down. You don't want that kind of responsibility with your computer, so much of the time people choose to essentially rent server space from companies that's sole purpose is to get you space/bandwidth on a simple computer that is always on. These are often called VPS's (virtual private servers).
So the first step I'd recommend is to grab a VPS for yourself. Digital Ocean is a great service that you can get a solid server from for $5/month, I would recommend starting there. There are bunches of other companies you can get VPS's from though if you prefer, probably the most popular alterntive being linode.
Once you've got yourself a VPS, log in to it using ssh. Usually it will look something like this:
ssh root#000.000.0000
...with the number at the end being the IP address of your server. Most VPS's are some flavor of linux, so being familiar with the linux command line interface is important. Once you're all set in your server, you'll want to do a few things. This is what I usually do, in order:
Install vim
For me, vim is the easiest way to edit files through the command line. This certainly might not be the case for everyone - some people prefer emacs, and some nano, which is a lot simpler. If you are interested in learning about vim, there are loads of tutorials around the 'net. If getting into vim isn't your thing, I'd recommend using nano instead wherever I mention it from here on.
To get it installed, we can use apt, which is aptitude, the package manager on ubuntu, the flavor of linux I'll use in this answer since it's a popular one for servers, and is the default for digital ocean. Just run apt-get update to make sure packages are up to date, then apt-get install vim to put in vim.
Add your ssh key
Add your ssh key to ~/.ssh/authorized_keys so that you don't need a password to log in. If you are unfamiliar with ssh keys, they are basically a pair of cryptographic keys that you can use to avoid needing to authorize with a password every time. By adding your public key to the ~/.ssh/authorized_keys file, you are essentially telling the server "this is my computer, so you don't need to ask me for a password to log in". Github has a great guide on how to generate keys. Once this is done, you can open the file with vim, get into insert mode, and paste the public key in from your local machine. Save and quit and you're set.
Install node.js
If you are trying to run a node app, you will of course need to have node! Installing node on linux is a bit different because the node installer I'm sure you used locally is graphical, where here you only have the command line. Luckily, it's not much more difficult with this set of instructions, which you can follow exactly. Make sure you do not just do the default apt-get install nodejs, as this will install an old version. Take the couple steps after the second paragraph to add ppa and get a newer version.
Deploy your app
Ok, so you have a machine that has node and theoretically could run your app. This is good news. Now we need to actually get the app onto the machine. There are a few ways you can do this. If you have ruby installed locally, you can use capistrano, a popular deployment solution. A lighter weight approach that I often prefer is deploy, although I don't think that will work on windows. You can also just use github or bitbucket - push your app to a remote repo then clone it down from your VPS (make sure to apt-get install git and set up your username first - if it's a private repo you'll probably have generate and add a key to get access to pull it down). However you manage to do it, get the files transferred.
Test your app
On your VPS, cd into wherever your app was put and run it. Make sure everything is working ok, and hit http://YOUR_IP:PORT, just your ip address followed by a port number that your app is running on after the colon. You should be able to see your app. If not check back to the terminal, it may have crashed. Sometimes you can find flukes when you are setting it up on a different system. If your app uses a database, you might need to get this configured too. You can google "ubuntu setup database name" and find some tutorials -- digital ocean has a pretty solid library of these types of tutorials themselves.
Install nginx
Nginx is a great way to serve multiple apps on one machine, and to handle domain names and such. I wrote an article on how to set up nginx that you can check out to learn the basics and get it installed. Once this is done, you can link up your app with a proxy_pass. Rather than try_files, which is what the article does to server static files, just drop in a proxy_pass statement to the port your app is running on instead, and nginx will direct traffic right through to your app. Here's an example, if you had your app running on port 1234 and your domain name was example.com
server {
server_name example.com;
location / {
proxy_pass http://localhost:1234;
}
}
This will just take traffic coming into the box from example.com and pass it to your app, which is awesome.
Get your domain in order
I have to assume you don't want to require people to use an IP address to access your app, and you want a domain name. Go grab one from wherever, and once you have this you need to edit the DNS records. I've found that it's easiest to use dnsimple for this, as not every domain registrar has solid dns record handling, and you can keep all your dns management in one place. Now, just put an A record on the root of your domain, pointing it to your VPS's IP address. After giving it a couple minutes for the records to propigate, a hit to that domain should go directly to your server - fantastic.
Now is the time to check through and make sure that your app is running properly and that your nginx configuration is correct (and that you have reloaded nginx). Make sure that in your configuration, the server_name mirrors the domain you set to point at your VPS. Make sure the port in the proxy_pass is the same as your app is running on. Once this has been confirmed, go to the domain, and if you did it right, your app will come up. Whoo!
Run it on a production server
Great, so we got our app running and it's online on the internet for the public to enjoy. Just about time to sit back and let everyone throw money at you, a common occurance whenever you get a site shipped. But don't recline too quickly, because the last thing we need is to make sure this app stays up and continues running even if something goes wrong, or you log out of your VPS, so you don't always have to keep a terminal window open running the app. For this, we can use what some call production servers -- servers made specifically to ensure that your app runs in the background and stays running all the time. Luckily, node has a few of these open source, my favorite being pm2. Check out this page, read the getting started instructions, install pm2 on your machine, and run your app. The process might look something like this:
npm install pm2 -g
cd path_to_my_app
pm2 start app.js
Since you ran it on the same port, your nginx configuration should remain the same, and your app should still be up if you visit the domain.
Phew, that was a lengthy process. Probably more than you expected - makes sense why something like heroku exists. So is this really worth it, running and maintaining the site yourself? I'd argue yes, and I host every one of the sites and apps I run like this. Here's why:
learning: I learn tons about how things work this way, and get much better at sysops.
cost: You can host like 20 sites on a single $5 digital ocean box. hosting is pennies.
control: Heroku sometimes goes down and it sucks because all you can do is wait for them to get it back up. If my site goes down, it's my fault and I can find out why and fix it.
I'm sure this answer was more than you ever expected to get here, but hope this helps! Getting from dev to sysops is a journey and sometimes can get really frustrating, but I promise once you have a good handle on things, it feel great and really helps your skills a lot.
Finally, I want to note that this is without a doubt an opinionated guide. There are tons of other tools and other ways to do these things -- the workflow I have here is just the way I prefer to do things. By all means feel free to tinker and suit the workflow to your needs once you have it under your belt! There are also lots of other details that could be added in here about setting up different databases, improving your deploy/restart flow, and securing your box a little more throughly. Would love to hear any feedback and add any of these pieces in if you or others are interested.
Google Platform has resources for Node developers. There is a tutorial shows you how to deploy a simple Node.js application to Google App Engine Managed VMs. Detail of the pricing is here.
Amazon Web Service (AWS) also has the similar service. Here is the tutorial. The AWS Free Tier is designed to enable you to get hands-on experience with AWS at no charge for 12 months after you sign up. You can investigate AWS as a platform for your Node.js application. Check it here.
I would like to start out by apologizing. I have very little knowledge in the areas of Linux and Servers. I have been asked at work to set up a Linux box running Apache Tomcat. The Server needs to be enabled to allow websockets. I managed to get Debian installed. During the installation it gave me the option to make it a web server, which I did. There are now some different folders and files that are named "apache" in the files system, so my guess is that I am in fact running Apache, but to be honest I'm not 100% sure, and if it is, I don't know if its Tomcat. I fumbled around a bit and figured out the IP address of the computer I installed on and tried going to that IP from another computer in the network and it worked. I was able to see the html file that I put in the /var/www folder on the host machine. I then went out and found a nice piece of code, someone was kind enough to share, that is suppose to test websockets capability but I cant seem to get it working. My thinking is that my server isn't allowing PHP to run. I came to this conclusion by testing. I took a web page from my other server, its written in PHP, that when opened will send a text to my phone. Its just a small piece of code that I used for testing. When I tried running it from the Linux server it wont run, meaning it wont send the text to my phone. So here I am. I realize I'm asking for a simple solution to a complex problem, but I'm under the gun so to speak. I have about a week to get this going, so I just don't have the time to really immerse my self in this stuff the way I would like to. My question in its simplest form is"How do I configure my server to run PHP?" Any help/advice would be greatly appreciated! Thank you all for your time and patience.
Have you tried running a simple PHP script like echo 'Hello World';??
If not then try, if it works then your PHP is up, but sockets are just not configured to use.
If it doesn't work then install Ubuntu, a simple newbie friendly interface for Linux, and then install LAMP, here its how to do it.
And don't panic.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 2 years ago.
Improve this question
There are a bunch of managed cloud based hosting services for nodejs out there which seem relatively new and some still in Beta.
Yet another path to host a nodejs app is setting up a stack on a VPS like Linode.
I'm wondering what's the basic difference here between these two kinds of deployment.
Which factors should one consider in choosing one over another?
Which one is more suitable for production considering how young these services are.
To be clear I'm not asking on choosing a provider but to decide whether to host on a managed nodejs specific hosting or on an old fashioned self setup VPS.
Using one of the services is for the most part hands off - you write your code and let them worry about managing the box, keep your process up, creating the publishing channel, patching the OS, etc...
In contrast having your own VM gives you more control but with more up front and ongoing time investment.
Another consideration is some hosters and cloud providers offer proprietary or distinct variations on technologies. They have reasons for them and they offer value but it does mean that if you want to switch cloud providers, it might mean you have to rewrite code, deployment scripts etc... On the other hand using VMs with standard OS as the baseline is pretty generic. If you automate/script/document the configuration of your VMs and your code stays generic, then your options stay open. If you do take a dependency on a proprietary cloud technology then it would be good to abstract it away behind an interface so it's a decoupled component and not sprinkled throughout your code.
I've done both. I did the VM path recently mostly because I wanted the learning experience. I had to:
get the VM from the cloud provider
I had to update and patch the OS
I had to install and configure git as a publishing channel
I had to write some scripts and use things like forever to keep it running
I had to configure the reverse http-proxy to get it to run multiple sites.
I had to configure DNS with the cloud provider, open ports for git etc...
The list goes on. In the end, it cost me more up front time not coding but I learned about a lot more things. If those are important to you, then give it a shot. If you want to focus on writing your code, then a node hosting provider may be for you.
At the end of it, I had also had more options - I wanted to add a second site. I added an entry to my reverse proxy, append my script to start up another app with forever, voila, another site. More control. After that, I wanted to try out MongoDB - simple - installed it.
Cost wise they're about the same but if you start hosting multiple sites with many other packages like databases etc..., then the VM can start getting cheaper.
Nodejitsu open sourced their tools which also makes it easier if you do your own.
If you do it yourself, here's some links that may help you:
Keeping the server up:
https://github.com/nodejitsu/forever/
http://blog.nodejitsu.com/keep-a-nodejs-server-up-with-forever
https://github.com/bryanmacfarlane/svchost
Upstart and Monit
generic auto start and restart through monitoring
http://howtonode.org/deploying-node-upstart-monit
Cluster Node
Runs one process per core
http://nodejs.org/docs/latest/api/cluster.html
Reverse Proxy
https://github.com/nodejitsu/node-http-proxy
https://github.com/nodejitsu/node-http-proxy/issues/232
http://blog.nodejitsu.com/http-proxy-middlewares
https://github.com/nodejitsu/node-http-proxy/issues/168#issuecomment-3289492
http://blog.argteam.com/coding/hardening-node-js-for-production-part-2-using-nginx-to-avoid-node-js-load/
Script the install
https://github.com/bryanmacfarlane/svcinstall
Exit Shell Script Based on Process Exit Code
Publish Site
Using git to publish to a website
IMHO the biggest drawback of setting up your own stack is that you need to manage things like making Node.js run forever, start it as a daemon, bring it behind a reverse-proxy such as Nginx, and so on ... the great thing about Node.js - making firing up a web server a one-liner - is one of its biggest drawbacks when it comes to production-ready systems.
Plus, you've got all the issues of managing and updating and securing your server yourself.
This is so much easier with the hosters: Usually it's a git push and that's it. Scaling? Easy. Replication? Easy. ...? Easy. All within a few clicks.
The drawback with the hosters is that you can not adjust the environment. Okay, you can probably choose which version of Node.js and / or npm to run, but that's it. You have no control over what 3rd party software is installed. You've got no control over the OS. You've got no control over where the servers are located. And so on ...
Of course, some hosters allow you access to some of these things, but there is rarely a hoster that supports all.
So, basically the question regarding Node.js is the same as with each other technology: It's a pro vs con of individualism, pricing, scalabilty, reliability, knowledge, ...
I personally chose to go with a hoster: The time and effort I save easily outperform the disadvantages. Mind you: For me, personally.
This question needs to be answered individually.
Using Docker is another way to simplify the setup on single Linux VPS. With Docker both development and production setups are faster, more robust, and more secure.
The setup is faster and more robust because you will be deploying ready Node.js image at once, without running any installation scripts. And it would be more secure because internal dependencies, such as database, can be hidden from outside world completely and accessible only from Docker internal network. On top of it, Docker significantly simplifies the upgrade process for underlying OS and Node.js runtime.
There are two ways to setup Node.js Docker environment. The first one – follow the instruction published here how to dockerize your application and deploy it with Docker, alongside with databases when needed. The guide gives the instructions for the development setup, the production setup will be similar.
Another way would be deploying official Node.js docker image and mounting application code as a volume or a folder to Node.js image. That would allow to update Node.js image going forward without re-building and re-deploying the application. Such approach solves long-standing problem with security patching of Docker images.
To help out with the setup of Docker on single machine - you can use Abberit Admin Panel. It will set up Node.js environment for you with a click of a button, including databases if you need them. The tool is free, and you can turn it off after you have completed initial setup. On the other hand, if later you decide to reduce maintenance tax of the production - you can migrate into managed service without any changes in the app.
Disclaimer: I am one of the founders of Abberit.