Ruby on Rails Stack on WebFaction

I’ve created a shell script to build a complete Ruby on Rails stack (application environment) on WebFaction. Although written for WebFaction users, the script is fairly generic, aside from a few minor details. All you have to do is edit a few variable assignments (install path, rails app name, and service ports) at the beginning of the script and execute. In less than 20 minutes, your rails app will be up and running with nginx reverse proxying (and fair load balancing) to a pair of thin servers and with monit keeping watch.

In case you’re unfamiliar with thin, it’s the likely successor to mongrel. It uses mongrel’s excellent http parser, provides various overall enhancements, and offers a number of features mongrel lacks. I specifically chose to use thin on WebFaction because of its support for unix socket listeners. For more technical information, see the comments in the script and the accompanying README.markdown file.

What you get:

  • Ruby
  • RubyGems
  • Gems: rails, merb, mongrel, mongrel_cluster, thin, capistrano, termios, ferret, acts_as_ferret, god, sqlite3-ruby, mysql, and typo
  • Git
  • Nginx (with nginx-upstream-fair third party module)
  • Monit
  • Startup scripts and working default configuration files for nginx and monit

UPDATE: New script with Passenger on nginx!

I will try to keep this script reasonably up to date at GitHub.

8 thoughts on “Ruby on Rails Stack on WebFaction

  1. Niki says:

    I have wanted one of these forever! THANKS for the great work

  2. ramonrails says:

    I am not unix/linux guru. Please excuse dumb question.
    Is they a way to minimize the memory usage and get deployment simplified for multiple rails applications on webfaction account?

    1. Is there a way to run multiple rails apps on the same ngnix as your script installs?
    2. Would passenger+REE+Apache be better solution? How do I do it?

    Regards, Ram

  3. ramonrails says:

    Forgot to leave the email. Here it is.

    My purpose is to use one webfaction account as QA server for multiple apps under development. That is why I asked the question about configuring multiple rails apps on one ngnix at webfaction.

    What would you recommend for a production app? webfaction? which stack? other provider?

    Regards, Ram

  4. Ram,

    As far as memory is concerned, you have to work within the constraints of rails’ overhead memory usage and the memory required by your particular application. Overhead is the amount of memory required per rails instance running a skeleton rails application. Memory usage permitting, you can certainly run multiple rails apps on WebFaction. I’d advise you to take a look at the memory usage on your development machine and choose your plan accordingly. My script sets up two thin instances for the sample app, but for your purposes you may only need one thin instance per app.

    Regarding your first enumerated question, it’s trivial to run multiple applications on “the same nginx”. You will have to duplicate the vhost configuration and make some small changes. For starters, you would create a “new app listening on port” from the WebFaction control panel. Take note of the port assigned to you. Duplicate the vhost file provided by the script and change the listening port to the port just assigned to you. Change the application path to the path of the new application in the vhost config file. Change the upstream socket paths to correspond with the new rails application’s thin sockets. You’ll also have to duplicate the info in the monitrc file that defines the thin servers for the first app and make sensible changes to reflect your new app. The last thing to do is to reload the nginx configuration and reload the monit configuration. (The quick and easy way is to kill nginx and quit monit, then start monit.)

    In response to your second enumerated question, you cannot (should not) use Passenger on WebFaction. Technically you could, but you’ll have to run your own instance of Apache, which negates the memory benefits of Passenger. The only enviable benefit of Passenger from my perspective is its ability to start up/tear down rails instances on demand. Although I’ve tried Passenger on my development machine, there has been no compelling reason for me to make the switch.

    After exhaustive research, I chose WebFaction for production. The alternative choice was SliceHost VPS. Both companies are exceptional. The deciding factor was that I didn’t want to maintain an entire Linux system. If you are passionate about Passenger, you might want to check out DreamHost. In my experience, the monit/nginx/thin stack is a good one.

  5. ramonrails says:

    Thanks for the details. Very helpful.

    I decided to use the mongrel configuration at webfaction for now. When I am ready for production, I will have them setup a VPS for me.

    Thanks again for all the details.
    Regards, Ram

  6. Andrew Perry says:

    I noticed you recently added some CouchDB setup stuff to your scripts. Does actually work to compile & install a functional CouchDB/Erlang setup etc on WebFaction ?

    If so .. bravo ! I’ve tried and failed to do it manually in the past – it would be great to hear that someone has got it working.

  7. Andrew, works as far as I can tell, except for the memcached gem, which is picky about the version of libmemcached. CouchDB requires a little bit of configuration. First of all, when starting couchdb, you may get a crash dump saying that cannot be found. The fix is to add it to the load path. Start couchdb like so: export LD_LIBRARY_PATH=$PREFIX/spidermonkey/lib && couchdb or add the first part of the command to .bashrc. Secondly, you have to edit $PREFIX/etc/couchdb/local.ini. Under the [httpd] heading, set port to the port you want couchdb to be on. If you haven’t done so already, create a new app in the WebFaction control panel (“app listening on port”). Next under bind_address make it the ip address of the server. If the binding is, then couchdb will only be accessible locally (by the server itself). If you want couchdb to be publicly available (to your browser), couchdb must be bound to your server’s ip address. If you choose to make couchdb publicly available, go to the [admins] heading (remove the semicolon before it to uncomment), and set up a privileged couchdb user. The plaintext password will be hashed and replaced by couchdb the next time you start it. I hope this helps.

  8. Andrew Perry says:

    Great, thanks for the details, these will be really helpful in getting it going.

Comments are closed.