Capistrano Series - Introduction to Capistrano 2

Before delving into the mini series, an introduction and explanation of what Capistrano is and what it does is needed.

Once setup, deploying your application changes (and it doesn't have to be Ruby on Rails) is a breeze with Capistrano.

Ease of deployment

Capistrano 2 makes all of the mundane and fiddly tasks a lot easier. You don't need to log into the Slice to upload and serve an updated revision of your application.

It can all be controlled from the workstation you develop on.

Do note that Capistrano is not designed to be used solely by Ruby on Rails - you can use it for many application structures and architectures.

What it's not

Capistrano 2 is not designed to build your server. It will not install Apache for you. It can be used for much more than uploading updates and restarting servers but it is not designed to be used as a replacement for building your Slice.

If you want an automated build system there is the deprec gem. However, it is not (as yet) compatible with Capistrano 2 (when it is, there will be articles aplenty!).


Let's have a look at how the vast majority of users develop their applications and deploy them to their Slice.


Normally, one of the first things to happen is a git repository is created. For the sake of argument (and to make my images clearer) I am going to assume it is on a remote server.

It can be on the same slice as the application server, on your local workstation or on another service such as GitHub - as long as both the Slice and local workstation have access to it, it doesn't really matter.

If you are unsure about setting up git, please the git article.

Git Workflow

Once setup, it is usual for developers to check out revision 1 of the application and start working on it: changes being committed as and when needed.


Once happy, the same sort of thing happens but from the Slice. Once the vhost has been setup and configured correctly, the developer logs into the Slice and checks out the latest working version, restarts the web server and then logs out again:

Git Workflow


I don't know about you but this all seems very repetitive - effectively repeating the same commands but in different locations.

This is where Capistrano 2 comes in:

Capistrano Workflow

As you can see, it bridges the gap that comes from working from the workstation and then working from the Slice.

It allows you to use the workstation to send a single command to the Slice which will update the application to the latest git revision, save old revisions of the domain folders and restart the server and mongrels.

Not bad for a single command and no messing about with logging into the server do all of this.


This makes for deploying updates a lot easier and a lot more convenient.

Yes, it's possible to log into the server to do all of this - it's what most of us do. But why makes life as a developer and/or sysadmin more complicated than it has to be?

Although installing, configuring and deploying Capistrano 2 is in the next article, once done, all you have to do to deploy your updated Rails is:

cap deploy



I hope this clarifies what Capistrano is intended to do and what it achieves.

Now your appetite has been whetted, we can move on and setup the Slice in the next articles.

Article Comments:

Mike Bailey commented Sat May 30 06:13:50 UTC 2009:

deprec is compatible with Capistrano 2. Please update. :-)

Steven Heidel commented Thu Apr 15 18:50:46 UTC 2010:

I'd also like to see a tutorial for deprec

Want to comment?

(not made public)


(use plain text or Markdown syntax)