I'm looking to group together the information on the current best practices for deploying a Rails application on a server I run (rather than, say, Heroku). The application is developed by multiple people, and they all have permission to deploy it. The application will run on a server that may have more than one application.

  • Use Apache or Nginx with Passenger
  • I use Ubuntu, but that shouldn't make too much difference.
  • Capistrano seems to be the best way to go to push to the server.

Now, some doubts I have:

  • Use RVM or not? Passenger can only use one version of Ruby, so it's sort of useless, no?
  • How would you structure user permissions and ssh keys? My thinking is that you definitely don't want to have the user be 'yourself' (dnw, say, on the server), but a role account. Is Ubuntu's www-data sensible for this, or would it be better to create a different user? One for each application? What sort of configuration (shell in /etc/passwd, for instance, groups, etc...) should these users have to make the system as safe as possible if someone finds a vulnerability in the web application? What sort of capistrano recipes would you utilize to achieve this?
  • Now, we add git into the mix: git needs to be able to pull without a password from the git server, so there's going to be some key exchange going on. How should the remote git setup look like in order to make things nice and safe?
  • Anything else that I'm not covering?
  • modrails.com/documentation/Users%20guide%20Standalone.html - looks like this may be a worthwhile option, since it has the advantages of Passenger, and lets you deploy with its own Ruby. – David N. Welton Jul 11 '12 at 8:22
  • Except each standalone passenger is it's own resource pool, and doesn't share worker counts with any other. – womble Jul 13 '12 at 6:45
  • 1
    You can use agent-forwarding to allow git on the deployment-server to authenticate to the git-server as you, which may (or may not) be useful. – nickgrim Sep 10 '12 at 12:22
  • Nginx/unicorn (Passenger is more trouble than it's worth, especially when you're dealing with multiple Ruby versions). Unicorns managed by daemontools / allah, because god rustles my jimmies.
  • rbenv rather than RVM (rbenv is designed to do one thing and do it well, rather than RVM's "do a painful half-job of everything" approach)
  • User per application, with SSH keys for each dev who has authority to manage each individual app.
    • You can run the application itself as a separate user and use ACLs to allow access to only those parts of the filesystem the app needs; this app user should not permit logins. I personally consider that to be overkill, but it's a possibility if you want to have a bit of incremental separation.
  • Capistrano is another "painful half-job of everything" tool; I recommend giddyup, although that might be because I wrote it.
  • 1
    +1 for suggesting some useful things, but I see unicorn as much more suited to a one site system, rather than a system with multiple applications: Passenger is good at allocating instances when needed, and removing them when they are idle. – David N. Welton Jul 9 '12 at 20:49
  • It's still more trouble than it's worth. – womble Jul 10 '12 at 3:36
  • 1
    It's the best option you have for a memory starved VPS with lots of little non-Heroku-able applications. Sometimes Unicorn and Thin are more trouble. – Rob Howard Jul 11 '12 at 11:32
  • That hasn't been my experience. – womble Jul 11 '12 at 23:04
  • I think having a system that is unable to dynamically de/allocate resources as needs be is a bad solution for certain types of situations (like mine), as Rob mentions. I have lots of little apps, some of which should minimize resource usage when they're idle or not used much, and if they get traffic, should start asking for and getting more resources, up to some sort of limit. – David N. Welton Jul 12 '12 at 15:02

I wrote an ebook on more or less this exact same setup, which is free for people on my mailing list.

It covers setting up a server with nginx, Unicorn, MySQL and rbenv from scratch and deploying (and updating) a sample Rails application to help you to understand how this process works under the hood.

If you think that's something for you, you can get it here.

Update: Quite some time has passed since I wrote this comment. Since then I have released Efficient Rails DevOps, a professional book on the topic which not only covers most of the questions above, but also how to do things in a controlled, reproducible way (using Ansible as configuration management and deployment tool).

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.