Part of the instructions for deploying a Rails app to OpenShift and CloudFoundry is to run Bundler. The basic idea of Bundler seems to be to gather up all the libraries (in Ruby they are called gems) your application depends on and to deliver them with the application itself. This seems like a good idea - it avoids having applications co-dependent on shared libraries, and ensures that an application runs with exactly the libraries it was developed and tested with. Unfortunately I find Bundler hard to understand and use, even though it;s command are simple. The initial symptom I found was that my Rails app would not run because Bundler had recorded the fact that my application used rake 10.0.2, while 10.0.3 was the one installed as a shared library on my virtual machine. Further, there was no available ubuntu package for rake 10.0.2. It was annoying that my application would not run, because Rake 10.0.2 was in fact in the directory structure of my application, in vendor/cache/, carefully put there by the "bundle install" command when it recorded the fact that I needed it. I believe that Bundler may be working as designed here, but I have not yet figured out how the whole thing works. What I think may be the case is that bundle install's job is only to copy the required gems into the cache directory so they will flow to the target on deployment. A further step is then required on the target to assemble the bundle from the cache. Just guessing. I then discovered that there is a option of the 'bundle install" command (--deployment) that might fix my problem, so I ran that locally. [With hindsight, it might have been better to do it on the target.] Bundler then created a new structure in vendor/bundle that was rather large. When I discovered that this structure was now going to take over an hour to copy to the target with (p)scp, I decided I needed a better solution. This sent me on a whole new adventure that can be the subject of another blog.