Continuous Deployment With Capistrano

In this post I’ll cover the Strano and how to setup it to trigger cap deploy task whenever you push/merge into the master branch of your project on GitHub.

Why Strano?

You might be wondering why we need a wrapper for a such great tool like Capistrano at all, so, here is advantages Strano gives you:

  • Centralized Deployment Approach: Setup once
  • History of Deployments: Who? When? What?
  • Use Anywhere: Web Based
  • Continuous Deployment (concept): trigger cap deploy when push/merge into the master branch.

Yes, those mostly valuable for the teams, but I believe single-man projects in some cases can also benefit from it.

Setup Strano for automatic deployments

Here is mostly typical for Strano installation except base_url variable which can be set through the strano.yml as described below or environment variable, e.g. STRANO_BASE_URL='' bundle exec rails s

  1. Clone from my fork:

     git clone git://
  2. Checkout push-deploy branch:

     cd strano
     git checkout -b push-deploy origin/push-deploy
  3. Configure database:

     cp config/database.example.yml config/database.yml

    NOTE: example file contains settings for sqlite3 database, but I’d recommended you to go with mysql to eliminate some weird transaction issues.

  4. Bootstrap:

  5. Configure Strano:

     cp config/strano.example.yml config/strano.yml

    The following variables are mandatory for our setup:

     # Strano's public SSH key with which it will attempt to clone Github repos via.
     public_ssh_key: MYPUBLICKEY
     # Strano's Github application client ID. See
     github_key: github-application-client-id
     # Strano's Github application secret. See
     github_secret: github-application-secret
     # Secret used to sign hook requests from GitHub.
     github_hook_secret: github-hook-secret
     # The application URL with a trailing slash, required for github hooks.
     # Can be passed as environment variable STRANO_BASE_URL=''

    NOTE: base_url is where your application can be publicly accessed by GitHub’s servers. See Post-Receive Hooks article to learn more.

  6. Start the app:

     bundle exec rails s

    Or whatever you do to start your rails application on the server.

  7. Start the worker:

     bundle exec sidekiq

    Check out the Sidekiq website for assistance on Sidekiq and its options.

    Usually it must be enough to have a Redis server up and running with default options.

That’s it! Once you sign-in with your GitHub account you will be able to start deploying your apps in no time.


Additional Resources

Eric Ries post on continuous deployment

Local Tunnels

Services that allows you to share localhost web servers to the rest of the world: