AboutBlogContact
DevOps & InfrastructureMarch 15, 2007 2 min read 131Updated: June 22, 2026

Zero-Downtime Deployments with Capistrano (2007)

AunimedaAunimeda
📋 Table of Contents

Zero-Downtime Deployments with Capistrano

It’s 2007, and if you’re still SSH-ing into your production server to run svn update and restart Mongrel manually, you’re asking for trouble. Capistrano has become the de-facto standard for Rails deployments, and for good reason. It turns a multi-step, error-prone process into a single command: cap deploy.

The Architecture of a Capistrano Deploy

Capistrano works by creating a specific directory structure on your server:

  • releases/: Contains timestamped folders for each deployment.
  • current/: A symlink pointing to the latest release in the releases/ directory.
  • shared/: Files that persist across deployments (like database.yml, logs, and system uploads).

When you run cap deploy, Capistrano checks out the code into a new releases/ subfolder, runs your migrations, and then atomically updates the current symlink. If anything goes wrong, cap deploy:rollback just points the symlink back to the previous release folder.

A Typical deploy.rb Configuration

Here is how we set up a multi-server Rails cluster in 2007:

set :application, "my_cool_app"
set :repository,  "svn://svn.example.com/apps/my_cool_app/trunk"

# We're moving to Git, but many are still on Subversion!
# set :scm, :subversion

role :web, "web1.example.com", "web2.example.com"
role :app, "app1.example.com", "app2.example.com"
role :db,  "db1.example.com", :primary => true

set :deploy_to, "/var/www/#{application}"
set :user, "deploy"
set :use_sudo, false

namespace :deploy do
  desc "Restarting mod_rails with restart.txt"
  task :restart, :roles => :app, :except => { :no_release => true } do
    run "touch #{current_path}/tmp/restart.txt"
  end

  task :after_update_code, :roles => :app do
    run "ln -nfs #{shared_path}/config/database.yml #{release_path}/config/database.yml"
  end
end

Handling SSH Keys and Roles

Capistrano uses the Net::SSH Ruby gem to execute commands in parallel across all servers defined in your roles. By using SSH keys (Agent Forwarding), you don't have to embed passwords in your scripts.

The role system is brilliant. You can tell Capistrano to only run migrations on the :db role, while restarting the application on all :app roles. This level of granularity is what makes it possible to scale from a single VPS to a massive cluster of rack-mounted servers.


Aunimeda provides DevOps engineering and infrastructure services - CI/CD pipelines, containerization, cloud deployments, and monitoring setups.

Contact us to discuss your infrastructure needs. See also: DevOps Services, Custom Software Development

Read Also

Gulp.js: Why Streaming is Better Than Temporary Files (2013)aunimeda
DevOps & Infrastructure

Gulp.js: Why Streaming is Better Than Temporary Files (2013)

Grunt has dominated the task runner scene for a year, but Gulp is here with a revolutionary 'code over configuration' approach. The secret? Node.js streams.

Dockerizing Your Legacy Rails App: No More 'Works on My Machine' (2013)aunimeda
DevOps & Infrastructure

Dockerizing Your Legacy Rails App: No More 'Works on My Machine' (2013)

The Docker revolution is just beginning. In 2013, we're using it to containerize legacy Ruby on Rails apps and solve the dependency nightmare.

Vagrant: Reproducible Dev Environments with VirtualBox (2012)aunimeda
DevOps & Infrastructure

Vagrant: Reproducible Dev Environments with VirtualBox (2012)

Stop saying 'it works on my machine.' Vagrant makes it easy to share identical, virtualized development environments in 2012.

Need IT development for your business?

We build websites, mobile apps and AI solutions. Free consultation.

DevOps Services

Get Consultation All articles