I think the fundamental problem is that on your laptop you use the system's package manager to manage gems and dependencies, while on the server you suddenly are forced to use RVM.
> ...while on the server you suddenly are forced to use RVM.
Why are you forced to use RVM on the server? A great number of the issues people face when trying to deploy Rails apps are environment based. Tools like rbenv and RVM are environment managers. They make all kinds of changes to things like PATH, GEM_HOME, etc.
In a production server environment, you want consistency and simplicity. Yes, you can use tools like rbenv or RVM, you but add layers of environment management on top of the base server environment. When you use these tools to manage Ruby on your server, any process or daemon that needs Ruby will first have to ensure that these tools are loaded and invoked properly. It's a layer of indirection that I feel a strong incentive to avoid.
Don't get me wrong. I'm not saying they're not good tools. Quite the opposite. I'm a huge fan of RVM, rbenv, and chruby. I have a deep appreciation of their contribution to the Ruby ecosystem, but I'm one guy. I have a reasonable understanding of Linux system administration, but the more layers of complexity I add, the deeper the water gets. At some point, I'm in over my head.
There are two really great options for installing Ruby on your production servers:
Note: Most Linux distributions give /usr/local/bin priority in PATH by default, which is why I use it instead of /opt. Using /usr/local/bin means you don't need to modify PATH.
1) Use ruby-build [1]. This is the plugin that rbenv uses to install Ruby, and you can use it without rbenv. Once it is installed, this simple invocation will get you a working Ruby install:
ruby-build '2.0.0-p247' '/usr/local'
Because of the reasons outlined in the note above, this type of Ruby install will "just work", even for utilities that shell out with bare shells like `sh -c 'some command here'`. This is because we installed to paths that work with the bare minimum environment.
2) Install from source. In the example above, ruby-build really isn't doing all that much. You still have to have the basic deps (build-essential, zlip, ssl, readline) in place in order to build Ruby, and you have to remain aware of any caveats introduced by new OS or Ruby releases.
I use option 2.
A great way to keep up with what's required to install Ruby on your system is to look at what tools like rbenv and RVM are doing under the hood. These tools act as collectors for the little hacks and workarounds (e.g., ref URL 2 below) that are occasionally required to install Ruby. If you're running a mainstream distro on a recent release, you really shouldn't need much in the way of hacks/workarounds these days. OS X is where a lot of the trouble lies.
EDIT: Above I said, "[ruby-build] isn't doing all that much", which isn't entirely fair. Ruby-build does do some really nice things like check MD5 hashes. It also checks for common caveats, which I kind of played off. I do the work of looking out for these things, but I'd certainly understand why someone wouldn't want the hassle, and ruby-build does a fantastic job of keeping up with these hassles and automating them away. In short, I want to be crystal clear that I am super appreciative of the work that the rbenv and RVM authors do. They are a tremendous asset to the community.
Here's my take on using rbenv to have the same kind of environment on your laptop and the server - damn fast : http://www.lambdacurry.com/damn-fast-production-ready-ruby-s...