7

I was wondering if there is any downsides from using rvm in a production server. What should I prefer, rvm or native installation and why?

JohnDel
  • 2,092
  • 8
  • 35
  • 64

5 Answers5

9

Don't do it, err, maybe do it

Simplicity is always rewarded.

Rvm is a development tool. Since you will not be switching Ruby versions back and forth dynamically on a production server, it can do no good and could create arbitrary levels of pain and suffering.

Update: Ok, we've got some excellent comments and know more now. For one, rvm was in fact a production tool first. (Who knew?) It looks like if an application doesn't bundle its own gem environment, rvm will do it at the system level, and that could be useful.

So there probably isn't a single answer to this question. If only one application runs on the server, or if all server applications are, say, Rails3, then rvm will not be needed. But other scenarios will benefit from the environment management.

DigitalRoss
  • 143,651
  • 25
  • 248
  • 329
  • 1
    but upgrading ruby is a lot easier with rvm – mpapis Apr 14 '11 at 23:49
  • 3
    A *"lot"* easier? On a production server you just install each ruby into its own directory. Your application server then needs to have that directory in its path. Not so hard. You can still install each Ruby side-by-side. You may well be running REE in production anyway, and it comes as a tarball that you just unpack into a directory. Problem solved. – DigitalRoss Apr 15 '11 at 00:52
  • 2
    Why do you need to upgrade Ruby on a production server? How often do you plan on doing so? Shouldn't the rate at which you plan on doing so make saving 30 minutes by using RVM irrelevant? – Rein Henrichs Apr 15 '11 at 01:24
  • 3
    I'm a big fan of RVM for developer sandboxes, but I don't see any big advantage to it on a production system. I compile the version of Ruby I need. *IF* I thought I'd need to upgrade the version later without totally gutting the machine, I'd set `--PREFIX` when running `configure` to install somewhere in `/opt`, and adjust the path for apps needing a particular version to reflect that difference. Then it becomes easy to install another version of Ruby in parallel. – the Tin Man Apr 15 '11 at 01:40
  • 2
    What if you are running a server with 1.8x apps and 1.9x apps? We have this going and it is hard to have 2 rubies going at once. RVM helps a lot in this case. Try using bundler with 2 rubies installed it is a pain. RVM is not just for switching rubies back and forth, it also makes running concurrent versions much easier. – Michael Papile Apr 15 '11 at 03:54
  • 3
    What if an evil alien overlord requires you to run 5 versions of Ruby at the same time? What if what if... It doesn't pay to invent requirements where none exist. – Rein Henrichs Apr 15 '11 at 04:52
  • 1
    fyi: RVM was not build as a development tool. Yes, it works great in development, but it was actually intended to be used in production. – rubiii Apr 15 '11 at 08:17
  • 1
    rvm simplifies ruby installation to one step (actually two if you count installation of rvm) it does all the checks for requirements and steps required for installation, if you miss some library then it will warn you, that is called time saver, no custom steps or instructions – mpapis Apr 15 '11 at 08:46
8

Use RVM. Because it is more simple.

You'll have all distributions in one place, all gems in one place, and you're using the same tool that you use in development. There are no performance issues either.

Michiel de Mare
  • 41,982
  • 29
  • 103
  • 134
  • Thanks a lot for clarifying that it does not have any performance impact :) – Sreenath Nannat Mar 04 '14 at 06:01
  • In 2022, we shouldn't be using RVM in production. Instead deploying a lean image with system ruby and all dependencies installed. Better if you can build it and push it to your registry with your CI pipeline – VP. Jan 31 '23 at 11:11
2

Use RVM, as that way your application has exactly what it needs, and system updates do not interfere or change your requirements. One host I set up had a distro version of 1.8, but I wanted to develop for 1.9.2. Rather than break the distro version, RVM lets me run a custom version. RVM plays well with passenger phusion for rails deployments too.

DGM
  • 26,629
  • 7
  • 58
  • 79
  • I didn't downvote you, but it is so easy to install Ruby from source into the directory of choice that I don't think these are real good arguments. – the Tin Man Apr 15 '11 at 01:45
1

Compile your own Ruby and MongoDB, PostgreSQL, MySQL, redis, and whatever other supporting tools you rely on. This way get full control over the versions used everywhere and you can apply any necessary security or bug fix upgrades at will without having to wait for your OS vendor to supply system updates and patches. Compiling your own also makes it easier to ensure that your development, staging, and production environments are all using the same versions of everything you need.

If using RVM makes it easier for you to build your own toolchain then use RVM. In any case, using the system supplied tools often leaves you a few versions behind and leaves you hanging when you need to apply critical patches.

mu is too short
  • 426,620
  • 70
  • 833
  • 800
0

system installation:

  • easier accessible

rvm installation:

  • possible to switch (fast) ruby
  • allow multiple version if required for multiple apps
  • easy upgrade of ruby version and management of gems update
mpapis
  • 52,729
  • 14
  • 121
  • 158