Read my latest article: 8 things I look for in a Ruby on Rails app (posted Thu, 06 Jul 2017 17:59:00 GMT)

Launching Ruby on Rails projects, a checklist

Posted by Mon, 15 Dec 2008 01:28:00 GMT

Since publishing this article, I have given a talk on this topic at Rails Underground 2009. I invite you to checkout the slides.

As mentioned in a recent post, I’m hoping to share some lessons that were learned throughout the process of launching a client project. Over the past few years, we’ve been part of several dozen client projects and the big launch date is always an anxiety-filled, yet exciting point for the client and our team. I wanted to provide a quick list of a few the things that our team considers vital before launching that next big project. While most of these things might seem obvious, it’s still good to cover the basics and I hope a few people find it helpful.


Our company has been offering Ruby on Rails hosting for nearly four years and a few years longer with the PHP5 and PostgreSQL world. Given that, we’ve seen customers come to us at the last minute before they launch and wanting to get things setup and deployed right away. Quite often, this is their first experience deploying a Ruby on Rails application and there has historically been a semi-steep learning curve to do this. It’s really encouraged that you get this stuff figured out ahead of time. If you’re lucky, some hosting companies might offer cheaper plans so that you can begin to get things setup a few months or ahead of time and upgrade your plan prior to the big launch. This is how our Rails Boxcar hosting plans work.

We’ve seen a lot of customers avoid engaging with a hosting company more than a week or two before their launch because they want to reduce their monthly expenses, but the reality is that if you end up saving yourself a few hours of work by not scrambling at the last minute to get things setup, the hosting costs will pay for themselves. Several of our customers have learned this the hard way and as a result, this has resulted in extra stress that might have been avoidable if things had been ready earlier on.

The basic process that our team is to get a real deployment environment setup as early in the design and development process as possible. Often times, this will be 4-6 months before launch on larger projects. In our process, we aim to have a staging environment that mirrors our production environment. We tend to use a Boxcar Lite plan for our own client projects and get the deployment process working and automated. When it’s time to launch, we can easily upgrade the Boxcars with more resources to one or more Plus plans.

If you’re in the market for a hosting company, do keep us in mind, but if we can offer any advice, be sure to find out how you can scale upwards to meet your initial 3-6 month growth targets. Don’t worry about planning too far ahead in the future, until you see how traffic picks up and how the application and databases perform, you’ll be spending a lot of time guessing without data. If you’re new to this and aren’t sure, I’d encourage you to speak with a Ruby on Rails deployment specialist.

A few things to consider here:

  • Get your Capistrano or Vlad deployment tasks setup early. Make sure everything works and set it up to work with multiple deployment environments. (staging, production, etc.)
  • Use the HTTP Basic Authentication, which is available in Ruby on Rails to keep peeping toms (competitors, search crawlers, spammers, etc.. ) out of your project while you’re deploying to your staging environment. We tend to give out a .htaccess user/pass with this method to the stakeholders so they can access the site whenver they need to.
    • Rails documentation on HTTP Basic Authentication: view docs
    • Watch a Railscast for using HTTP Basic Authentication: watch screencast
  • Get your automated tasks (cron jobs) setup way before launch. Verify that things are working here at the right times
    • Extra-credit: Check server time settings to make sure you’re not running big tasks at time periods when heavy traffic is expected
  • Make sure your hosting provider has monitoring setup. It’s good to gauge uptime % from launch
    • Extra-credit: Setup your own monitoring with Pingdom or similar service to make sure you know when things are down. (You can audit your hosting provider this way!)

There are a handful of really great hosting companies out there for Ruby on Rails. Be sure to do your homework early! This isn’t something you want to do at the last minute.

Reminder: Keep your project releasable at all times.

Search Engines and Analytics

Before the big launch, be sure that you have outlined a consistent pattern for managing the HTML page titles on each page. Getting targeted traffic to your new web application is (usually) vital. Our team has adopted a basic pattern that we use throughout the application. This way we don’t have to go through at the last minute and figure out where titles are and/or aren’t being set.

In a previous post, I shared a basic plugin that our team uses on projects to manage page titles on a view-by-view basis.

Additionally, be sure to take advantage of using descriptive permalink URLs.

Another tip is to setup your application with analytics (google analytics is free!) If there is one thing that I wish we had setup from day one on every project in the past, was a set of conversion goals. So, be sure to get into your analytics account and prepare your application so that you can track these goals from the moment your application is launched. Collecting as much data about your visitor’s usage habits is going to help you in the coming weeks and months as you tune things based off of feedback and this data. Also, after you begin to introduce changes, you can analyze these metrics to verify that you’re improving things and not the opposite.

So, be sure that you are doing the following:

  • Have implemented descriptive page titles and urls
  • Are ready to track your site visitor’s usage habits from the starting gate
    • Conversion goals for obvious things like: sign-ups/registrations, viewing your product tour, contact requests, etc.

When Things Go Wrong / Tracking Exceptions

What happens when things go wrong? We’ve been amazed by how many projects we’ve seen have been in production for months/years and lacking something that seemed so obvious. Exception notifications! All too often, we’ve seen teams totally unaware that things were failing for their customers and not being reported to anybody. The easiest way to track exceptions in the past was to use the exception_notification plugin that the Rails team manages. You can have this plugin send your development team emails with a backtrace and all the goodies that’d normally show up in a 500 error. At a minimum, you should be using something like this.

  • Tip: Make sure your hosting environment can send out emails! (otherwise, you’ll never know about these problems…eek!)

However, in the last year, the Rails community has seen two options, Exceptional and Hoptoad introduced for managing exceptions. Our team has only used Exceptional so far, because our good friends at Contrast invited us to be early beta-testers for their new service. We love the Exceptional’s integration with Lighthouse, which is the bug/issue tracking application that we’re currently using. With Exceptional, our team is able to search through and track exceptions in our application and have a good meter on the overall health of our application. This solution works so much than the email-based approach because we can track which exceptions have been opened and sent to Lighthouse and if they’ve been closed by someone already.

I’ve heard great things about Hoptoad as well, but have yet to test it out. Would be interested to read a comparison between the two and am curious if there are other services for this currently.

Non-default 404 and 500 pages

Honestly, this is one of those things that we tend to forget about until the last minute. When you’re launching a new project, you’re bound to have a bug and/or a few broken links not accounted for. What you want to avoid is having your customers end up on an unhelpful page that looks like this:

The page you were looking for doesn't exist (404)

It doesn’t take too long to put something together that is a bit more helpful for your visitors.

AlphaClone — Page not found

So, do yourself a favor and add a ticket for your designers to design a custom 404 and 500 pages to replace the defaults that are provided by Ruby on Rails in public/.

Hold your client’s hands

If you’re working with startups, do remember that this is quite possibly their first launch. It’s important to remember that they’re going to be going through their own spectrum of feelings and it’s our job to help get them through the process with an eased mind. Show them that you have things covered, that things are ready to go, alert them when things pop up… in a nutshell. Keep them informed about the challenges and do what you can help to manage their stress. If they’ve just contracted you for an extended period of time to help get their big idea designed and developed, remember that this launch is just the beginning of the race for them. They have a big journey ahead of them and you just helped them get their new car engine built. Make sure they know that things are likely to breakdown along the way, need to be refueled (refactor! refactor!), and need service repairs. The worst thing you can do is set the expectation that nothing will go wrong once their application is released into the wild. They need to budget for this early on so that they can pace themselves after launch. (this is a big topic definitely worth of it’s own post)

Just remember that this should be a big celebration for your team and client. Remember to celebrate! (and then follow it with a retrospective)

In Conclusion

As mentioned, these are just a handful of things that we have learned to avoid overlooking (through trial and error). I’m hoping to share more thoughts on launching in the near future and would love to hear from all of you on things that you’ve come across. What works? What doesn’t work?

What is on your checklist for launching successful projects?

Related Articles

Expanding Rails Boxcar packages

Posted by Mon, 04 Aug 2008 14:30:00 GMT

If you’re in the market for a new hosting provider for your Ruby on Rails application, you might take a look at the new options for Rails Boxcar. We recently expanded our service offerings into three pricing tiers as well as custom packages for those who need a bit more.

A few things that we’ve recently added support for:

  • Provide us your SSH key during sign up!
    • Allows us to keep your server even more secure by avoiding sending passwords over the net
    • Other fun features related to this coming soon
  • Auto-configured Nginx w/Mongrel cluster
  • Phusion Passenger (mod_rails) support! (for those with mixed-environments)
  • Continued development of Boxcar Conductor)
  • ...more in the works!

The best part is that we can get you up and running with a new Boxcar now for as low as $59/month USD.

For more information, visit:

If you have any questions, don’t hesitate to contact us.

Boxcar Conductor plugin moved

Posted by Fri, 23 May 2008 09:23:00 GMT

Update. We’ve moved the Boxcar Conductor plugin for deploying Ruby on Rails applications to a new location on GitHub.

You can still submit bugs/feature requests on Lighthouse here:


Boxcar Conductor: Rails deployment made easy

Posted by Tue, 15 Apr 2008 17:16:00 GMT

In a previous post, I showed how we’ve been working on an interactive deployment process for Rails applications to reduce the time it takes to deploy to a Boxcar.

We began to move our Boxcar deployment recipes into it’s own Rails plugin and just made it available on GitHub.

Introducing Boxcar Conductor

The Boxcar Conductor plugin aims to automate the entire process for deploying to your Boxcar. We’re down to just a few simple commands to run to get your application up and running. While mileage may vary with other hosting providers, we did want to open up this work to the community and centralize our work with the community of Boxcar customers who have helped us build and test these tools.

Install Boxcar Conductor

If you’re running on Edge Rails… you can take advantage of the new support for installing plugins in git repositories.

  $ ./script/plugin install git://

note: If you’re not using edge rails, you can download a tarball and install the plugin manually.

Installing the plugin will add a custom Capfile and config/deploy.rb, which has a few things for you to define based on your Boxcar subscription.

Configure Your Boxcar

Once the plugin is installed, you can run the following task:

  $ cap boxcar:config

This will ask you a few questions about your deployment needs.

Uploaded with plasq’s Skitch!
  • Which database server will you be using? (along with db user/pass info)
  • How many mongrels should run in your cluster?

After a few quick multiple choice answers, you’re application is ready to be deployed and you can run an Boxcar-specific deployment task.

  $ cap deploy

We’ve also created a new public project on Lighthouse so that you can submit tickets and ideas to us. With Boxcar, we’re really aiming to remove as many steps from the deployment process that aren’t necessary.

To follow along, visit the project on lighthouse or GitHub.

If you’re interested in learning more about Rails Boxcar, feel free to drop us a line.

Related Posts

Deploying Rails with an interactive Capistrano recipe to your Boxcar

Posted by Thu, 28 Feb 2008 22:27:00 GMT

I wanted to share something that I’ve been meaning to share on here.

When we began planning Rails Boxcar, we really want to reduce the amount of work that it took to setup and deploy a VPS for a Rails application. During this period, we began to look at the deployment process itself and began working on an interactive tool for developers for setting up their deployment environment on their Boxcar instances. So, we worked with few customers to develop an interactive Capistrano recipe.

The Goal? Spend less time configuring the server or editing recipe files.

During the initial setup, we can have the customer provide a few details from the safety of their Rails application directory by answering the following.

  • What database server will you be using? (PostgreSQL or MySQL)
  • What port does your database run on? (if different than the default for your db server)
  • What is your database username?
  • What is your database user’s password?
  • What port will your mongrel cluster start with?
  • How many mongrel servers should your cluster run?

Great… setup the server and let’s deploy!

Uploaded with plasq’s Skitch!

Feel free to snag our interactive Capistrano2 recipe.

We’re trying to take the pain out of deploying your Ruby on Rails applications with Boxcar.

On a side note, we’re in the process of expanding our team and recently hired Alex Malinovich. Do stay tuned as we’ll be posting important announcements about changes to our Rails hosting services in the next few weeks. (grin)

YSlow and Rails performance: Getting UJS and AssetPackager to play nice

Posted by Fri, 27 Jul 2007 18:40:00 GMT

Yesterday, I started to dig deeper into YSlow and decided to pick an application that we recently launched for a client. The performance grade that I saw at first was an F, which wasn’t surprising to me because we knew that there was going to be some fine tuning in the near future.

There is a lot of JavaScript in this application and we have several files to break up stuff to make it more maintainable. However, in production, we really don’t need to send the client (browser) 19 different JS files. We’ve been using mod_deflate to compress these files, but it doesn’t solve the problem of having several connections opening to download all the necessary JavaScript. The same is true for our CSS files.

At RailsConf, DHH announced that an upcoming version of Rails would bundle all the stylesheet and javascript files into one file and compress it. We’re running on 1.2.x for this application and decided to look at the AssetPackager plugin as a good solution to this problem.

I installed the plugin via piston and ran the following task, which is provided by AssetPackager.

rake asset:packager:create_yml

This went ahead and created config/assets_packager.yml. I then went ahead and updated our capistrano configuration to call the rake task after updating the code on the server when deploying.

desc "all of our other tasks/commands to run after updating the code" 
task :after_update_code do
  # all of our other tasks/commands
  run "cd #{release_path} && rake RAILS_ENV=production asset:packager:build_all" 

The first thing that I noticed was that the yml file that gets generated will not make any assumption as to what order the javascript libraries should be loaded. So, immediately, line 1 of our compressed javascript file was causing an error as the code was trying to reference a library that hadn’t been defined yet (showed up later in the file). So, when you do this, you’ll need to organize the yml file to load things in order that they are needed. This was also a good opportunity for us to say, “oh, we’re not using that one anymore. Let’s remove it.”

- base: 
  - prototype  
  - effects
  - scriptaculous
  - controls
  - dragdrop
  - application
  - slider
  - pngfix
  - nav
  - lowpro
  - lightbox
  - folder
  - builder

Great, so we re-dployed and everything at first glance seemed fine… or so we thought!

We used the unobtrusive javascript plugin for this project and it seems that we couldn’t just compress every single file. Each page has a behaviors javascript file and since everything was being compressed into one file (and cached), RJS calls quickly broke throughout the site. OH NO!

So, I opted to merge all of the other javascript files and use the standard way of including unobtrusive javascript in the application layout.

<%= javascript_include_merged :base %>
<%= javascript_include_tag :unobtrusive %>

We also removed lowpro from the list of javascript files to compress since the ujs plugin is currently including this when we call <%= javascript_include_tag :unobtrusive %>. I plan to look into modifying this so we it’ll only include the page-specific behaviors and not load the lowpro javascript file (so we can compress that as well).

Once this was re-deployed, we saw that the RJS issues were resolved and everything felt to be loading quicker. But, let’s look at YSlow again for step 1 in improving the performance of the application.

side note: the following grading was also after making some other adjustments that were suggested by YSlow, which I’ll discuss in another blog post soon.

So, where we once had a grade F, we now have an D… which is due to the client having us add several (four) external javascript files for mint, google analytics, etc. We’re only loading 3 javascript files for the application, when we were originally loading many more.

Obviously, there is some more tuning to be done, but we went from a grading of 43 to 74 in about three hours of time spent reading the YSlow documentation, adding asset_packager, and making various tweaks to our web servers (as suggested by YSlow).

Until next time…

Related Posts: