Is RVM production ready?

Question

RVM is great for developing on your local machine. But is it safe on a production machine?

Answer 1

I've pretty much used RVM on all my production servers running rails apps!. RVM has not let me down.

Answer 2

I disagree, especially if you're using any kind of automated production process (puppet, chef, fog, etc) and you have more than one or two machines.

We've had issues where version X of RVM worked in a completely different way to version Y of RVM (different default Rubygems versions, different default gemset configs, complete changeup of how system wide install works), breaking our automated provisioning process.

Not an issue if you're developing and on hand to tune things, a killer if you have an unattended scripted / puppet install. We worked around these issues by locking to a particular RVM version, but I remember having a conversation with Wayne where he discouraged this. If we kept using RVM in prod, we were going to actually package it into a series of .debs (one for the install, one for each Ruby).

The way that .rvmrc prompts by default and can only be overriden in the homedir ~/.rvmrc (and not the system-wide one) was also unhelpful.

I actually like the way that RVM will change up and do things this way in development - nothing sucks more than being held back by backward compatibility. This approach, however, cost us some time (and pulled hairs) in production/staging/uat/test.

Answer 3

I built RVM for production and added the developer 'niceties' later on. If you would like more information read the documentation on the website and come talk to me in #rvm on irc.freenode.net sometime during the day EDT most days.

Answer 4

I've been using RVM on a production webserver for over a year now with zero problems. I've kept it pretty up-to-date, running rvm get head frequently. Zero issues, ever. :)

Answer 5

Since RVM is just a fancy way of downloading, isolating and switching between existing Ruby implementations, I'd say that it's as production ready as whatever ruby implementation you're currently running it with.

Essentially, all RVM does is point your path at a specific Ruby implementation. This is exactly what happens when you use your *nix distribution's Ruby implementation. The only real difference is that your path will be re-written so that when you run ruby -v it will run a ruby from your current user's .rvm directory instead of a global system directory like /usr/local/bin.

I'd go even further and say that using RVM is a better solution than using what generally gets installed in a *nix distro because it makes it easy to sandbox the specific ruby implementation on a per-user basis. RVM also makes it possible to attempt switching rubies (ie; from 1.8.7 to 1.9.2) on your production app while keeping a solid rollback strategy in place if something doesn't work quite right. It also makes it easier to keep old applications running on one version of Ruby, while switching new apps to more current versions.

Answer 6

I guess there's two parts to this question:

1. Is RVM intended to be for production machines, as opposed to development machines?
2. Is RVM reliable enough software to be used on production machines?

For (1), Wayne E. Seguin has stated that it's intended to be used on production machines. There's no point in disputing his intent.

For (2), I'm not so sure. Is it appropriate to use software that has a new version number every couple of days on a production machine? Also, RVM once deleted my entire ~/ruby directory. To Wayne's credit, when I told him about it, he fixed it that night, but that doesn't exactly say "production ready" to me.

Edit: I've just read about bumblebee's deletion of /usr, and I'll just say - it could have been worse! LOL.