As some have notes, even if you go with a hoster, it's worth going through once to understand what's going on. Hopefully my links help ...
–
bryanmacSep 30 '12 at 0:55

Thanks man, I believe I will go with Linode VPS for now so your links would be very helpful, although I was hoping to find some less obvious cons and pros specially on hosted solutions which seem quite blackbox to me now.
–
YousefSep 30 '12 at 5:09

OK - makes sense. Added a bit more on pros/cons. I'll follow up if I think of more ...
–
bryanmacSep 30 '12 at 12:42

I've never used the cloud hosting, and I've always used VPS for Node. It's actually been really easy to manage Node on a linux box. However, have you considered alternatives to Linode? I've always found them to be comparatively expensive. Digital Ocean is fairly new and has great prices with quality service.
–
SamOct 12 '13 at 20:04

I'm finding these easy one touch cloud providers like Nodejitsu and Heroku having a dark side when I use them in production. The memory is really small per "VM", like 256MB small. Its like they design their systems to HAVE to have load balancing. Have only one node and its sorry slow and sometimes lags to wake up. Linode and Digital Ocean are pretty zippity quick and there is Amazon too but these require you to man up.
–
Jason SebringJan 8 '14 at 7:33

2 Answers
2

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 had 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 alot 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 en 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.

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.