This article is deprecated and no longer maintained.
Ubuntu 12.04 reached end of life (EOL) on April 28, 2017 and no longer receives security patches or updates.
This article may still be useful as a reference, but may not follow best practices or work on this or other Ubuntu releases. We strongly recommend using a recent article written for the version of Ubuntu you are using.
If you are currently operating a server running Ubuntu 12.04, we highly recommend upgrading or migrating to a supported version of Ubuntu:
If you already know what Node.js is what it’s for and why it’s cool, then skip straight to the installation directions. If you want to know a bit more about node and it’s ecosystem read on.
For those who haven’t heard node.js is, it is the hot new cool kid on the block in web application development. It lets you write web apps that use Javascript on both the server and the client, so you don’t need to know multiple programming languages to program your website. It’s also really good at handling real-time concurrent web applications, which makes it a great choice for a lot of modern web apps.
The downside though is that all these cool new features are really, really new. As a result, getting up and running with node.js isn’t as easy as, say, getting WordPress up and running on your web server.
This is the first in a series of how to install, code in, and use node. Joyent, the team behind node.js, has been improving node.js at a frantic pace, to the point where there are multiple releases of the software every month. For the most part, they’ve done a pretty good job of keeping things compatible; the things you write for one version of node will work just as well in the next. But nonetheless, sometimes a particular node app will only work with one version of node. And you will need to upgrade or downgrade your node.js install in order to use it.
This used to be a pain, but the node community has come together and created a great solution that lets you easily manage all your node installations and change node versions whenever you feel like it. It’s called NVM, or the Node Version Manager.
The install process couldn’t be easier. Once you’re logged into your VPS, run this command:
curl https://raw.githubusercontent.com/creationix/nvm/v0.11.1/install.sh | bash
You’ll see some output fly by, and then nvm will be installed. You will see a line that says:
=> Close and reopen your terminal to start using NVM
It’s not actually necessary to log out, we just need to make sure that the changes nvm made to your path are actually reflected, so just do:
source ~/.profile
Alternatively, run the command suggested in the output of the script. Now type:
nvm ls-remote
Should you see the error, -bash: nvm: command not found
it may be because git is not installed.
Go ahead and install git and rerun the script:
apt-get install git
And you will be shown a list of all the available versions of node.js. You can always find out the latest stable release by heading to the node.js website, where it’s printed in the center of the page.
To install version 0.10.13 (the latest as of this writing) type:
nvm install 0.10.13
If you type:
node --version
You will now see that node v0.10.13 is installed and active. If you had an older node app that only works with node v0.8.16, and wanted to downgrade, then you would input:
nvm install v0.8.16
to install and switch to v0.8.16.
When you’re done and want to switch back to v0.10.13, you can do so with nvm’s use command:
nvm use v0.10.13
Nvm is great and makes switching between node versions easy and convenient. However, there’s one caveat. If you type:
which node
you will see something interesting. Nvm installs node.js inside your user’s home directory. This is fine for development, but if you want to actually host node applications, you don’t want to install the latest new version of node via nvm and discover that you’ve inadvertently caused your production node app (which can be incompatible with the latest node.js) to stop working. It’s best to install one copy of node globally so that other users can access it, and use nvm to switch between your development versions.
To do this, run the following command (entering your user’s password at the prompt):
n=$(which node);n=${n%/bin/node}; chmod -R 755 $n/bin/*; sudo cp -r $n/{bin,lib,share} /usr/local
The above command is a bit complicated, but all it’s doing is copying whatever version of node you have active via nvm into the /usr/local/ directory (where user installed global files should live on a linux VPS) and setting the permissions so that all users can access them.
If you ever want to change the version of node that’s installed system wide, just do another nvm use vXX.XX.XX to switch your user’s node to the version you want, and then re-run the above command to copy it to the system directory.
To check that it works, become the root user and do another which command to make sure that node is now installed to /usr/local/bin:
sudo -s
which node
You should see:
/usr/local/bin/node
Congrats! Node.js is now installed and ready for use. Enjoy!
Thanks for learning with the DigitalOcean Community. Check out our offerings for compute, storage, networking, and managed databases.
This textbox defaults to using Markdown to format your answer.
You can type !ref in this text area to quickly search our full set of tutorials, documentation & marketplace offerings and insert the link!
BE CAREFUL! The command listed above, is actually not well thought out and could lead to SUDO breaking (at the least) on many systems. Consider the following
This recursively will change permissions on all executable files within /bin to 755, which is not a good thing in the case of SU or SUDO, which requires the sticky bit being set and will result in the following, unwanted behavior as the final part relocates the entire /bin to /usr/local/bin…
Perhaps a safer way to do this command, would be to remove the wildcard ( * ) and do something like this…
Even wild card on say /bin/n* would include - /usr/bin/nproc - used for limiting system processes and resources… either way… I really suggest NOT using that command and add the following code for each users ~/.profile
This is not a complete example but using environment variables is a lot safer than changing system binary permissions and copying these without the correct permissions, setuid, stickybit etc… I appreciate the article and thanks for sharing! :-)
@erelsgl You could also do
nvm alias default XX.XX.XX
Hi - I maintain nvm. Please update your link to use the latest tagged release (per the readme on the github repo). Installing from
master
is dangerous, as you may install unstable code. Similarly, please pipe it to bash and not to sh (as is in the readme).Another problem I just encountered is that, after reboot, the node version goes back to the previous one (see also this SO post: http://stackoverflow.com/questions/9170713/node-js-version-goes-back-to-0-4-form-0-6-on-reboot-nvm ). To solve this, I had to add the line “nvm use xxx” to my .profile script.
**Great ** this helped alot.
Latest install script:
wget -qO- https://raw.githubusercontent.com/creationix/nvm/v0.33.6/install.sh | bash
source: https://github.com/creationix/nvm#install-script
I know that isn’t the best way to resolve the “user variable environment” issue, but here is the way that I found to set node in env everytime that change node version by using
nvm use <version>
command:This code is a piece found in
~/.nvm/nvm.sh
that log when thenvm use <version>
command is runned successfully.The difference here, is that
sudo
password will be asked always that you runnvm use <version>
[]'s
Hi, I’m running a Centos 7 and I followed all the steps from above, so far everything goes ok, but I’m having this issue, all my logged in users can see and make use of node js, except for one: the root user, it cannot see or execute node, even thought when I execute:
which node
I get this message: “/usr/bin/which: no node in (/sbin:/bin:/usr/sbin:/usr/bin)”
It only happens with the root user.
By the way great article.
I’m getting this response when I run the command to fix which node:
cp: cannot create regular file ‘/usr/local/bin/node’: Text file busy
Broke my sudo D:
You should listen to mrhassell’s comment further up this comment thread and change that part of the article to something safer. Luckily this just happened on my personal server and reinstalling Ubuntu won’t be hard. Here’s the whole story.
Now I know not to trust odd-looking commands even on digitalocean…