Engine Yard Developer Center

How Your Ruby Code Is Deployed on Engine Yard Cloud

General concepts

There are two components that facilitate code deployment:

  • Client-side component. This component connects (via SSH) to the application master of your environment and ensures that the server-side component is installed and is the correct version. The client-side component then invokes the server-side component on the application master to coordinate code deployment.
  • Server-side component. This component ensures that it is installed on all other instances in the environment. Server-side then manages and coordinates the code deployment process whenever the client-side component requests a deployment.

1. Code fetch

  • On the application master, the source code is fetched from the git repository, then the chosen branch is checked out into /data/<appname>/shared/cached-copy. The application master then copies this (via rsync) to all the other instances in your environment.
  • On each instance, the contents of /data/<appname>/shared/cached-copy are copied to /data/<appname>/releases/<timestamp>.

2. Gem bundling

After your code is copied to all instances in your environment, the server-side component checks for the existence of a Gemfile.

  • If a Gemfile is found, the bundler gem is installed and the command bundle install is run on each application instance.
  • If you need a specific version of bundler, specify it in your Gemfile.
  • We suggest you generate a Gemfile.lock to ensure consistency across deployment environments.

3. Default configuration

After your application gems are installed, the server-side component generates and symlinks configuration files and directories for your application.

  • Configuration files and directories necessary for your application are generated or symlinked and put into place. Examples of these files include: config/database.yml, config/mongrel_cluster.yml, config/newrelic.yml, the log directory and more.

4. Database migration

After default configuration has been setup, your database migrations are run with appropriate deploy hooks.

  • The deploy hook deploy/before_migrate.rb is run.
  • The migration command specific to your application is run (see the --migrate option).
  • Finally, the deploy hook deploy/after_migrate.rb is run.

After migrations and their deploy hooks have been executed, your application symlink is created.

  • The deploy hook deploy/before_symlink.rb is run.
  • Your application symlink is created.
    /data/<appname>/current points to /data/<appname>/releases/<timestamp>
  • Finally, the deploy hook deploy/after_symlink.rb is run.

6. Restart application servers

After your application code is in place and has been appropriately symlinked, restart your application servers.

  • The deploy hook deploy/before_restart.rb is run.
  • Your application servers in your environment are now restarted. For example, if your environment is using Passenger, the server-side component will touch the file /data/<appname>/current/tmp/restart.txt to tell Passenger to restart.
  • Finally, the deploy hook deploy/after_restart.rb is run.

7. Final cleanup

If there are more than three previous releases in /data/<appname>/releases, all but the most recent three are removed. Your deployment is now finished.

If you have feedback or questions about this page, add a comment below. If you need help, submit a ticket with Engine Yard Support.

Was this article helpful?
10 out of 10 found this helpful
Have more questions? Submit a request


  • Avatar
    Alan Hogan

    This document says it was posted "Feb 16 10:02". Of what year? Obviously this is a worthless date format, because it neglects year — though helpfully provides time, though if I actually cared, I’d be left guessing whether that’s 10AM or 10PM.

  • Avatar
    Alan Hogan

    Can’t seem to edit the previous comment, but anyway, let’s pretend I used a friendly tone to suggest a better date format.

  • Avatar
    Keri Meredith

    Hi Alan, OK sure, we'll go with friendly. :) Thank you for the feedback on the date format. We are currently working with our help desk vendor to get the last edited time stamp added, and we will look into adding the year as well.

    FYI - Most of the docs were loaded into the help desk in February 2012, so you can consider that date as a baseline. The time format is 24:00 hours, so you can tell it was a.m. thanks, kjm

  • Avatar
    Alan Hogan

    Thanks, Keri. I appreciate the prompt response and am looking forward to those changes.

  • Avatar
    Jamie Miller

    Hi Alan - I just wanted to update you to, again thank you for your feedback, and let you know that I changed the timestamps from a 24:00 format to a 12 hour clock. This makes the timestamp more obvious when looking at it. This will also be reflected in timestamps in the ticket comments.  Regarding the year, I have passed this feedback on to Zendesk, and they are going to look into it.  They did confirm that anything posted within the current calendar year will not show the year, but anything posted in past years will show the year (ie, anything added in 2011 or earlier).   Thanks!  Jamie


  • Avatar
    James Stephenson

    How do changes from Github get implemented? Let's say I have my application up and running, but then make a change to a screen; what do I need to do to get that change into the live application?



  • Avatar
    J. Austin Hughey

    Hi Jim,

    Generally the workflow is like this:

    1. Make changes in your code; run tests locally, make sure it's working
    2. Run a git add <filenames changed> and git commit -m "your commit message here" followed by a git push to whatever branch you're using (e.g. 'git push origin master')
    3. Once the code has been pushed to GitHub, you can deploy from the dashboard or from the Engine Yard CLI. 

    Once code is on GitHub, it can be deployed to your application by our deployment process, so it's generally a two-phase process (including support steps for each phase as above). The deploy will bring down the new code, put it in a new directory, do some symlinking and restart the application (as well as run database migrations if necessary), just as this document describes.

    More information on deploying can be found here:

    Deploy From Your Dashboard

    Deploy From the CLI

    Hope this helps!

  • Avatar
    Keri Meredith

    Hi, I liked this Q&A so added it to the FAQ forum. thanks! kjm

  • Avatar
    Reid Parham

    Regarding step 7, is it possible to configure how many releases are kept?

  • Avatar
    Jes Sherborne

    Is there a corresponding document that covers how this works for node.js applications? Not all of these steps apply (or they apply but are presumably being done in a different way).

  • Avatar
    Keri Meredith

    Hi Jes, No, I don't think we have that doc. A very good suggestion though. Will see what we can do ... thanks! kjm


  • Avatar
    You don't need a CRM

    Hi, I would like to know if it is possible to increase the number of release kept after deploying? I cannot find it in the documentation.

    Thanks in advance.


  • Avatar
    Matt Scilipoti

    Could you include some information about asset compilation?

  • Avatar
    Brent Jacobs

    At what point are the chef recipes run?

  • Avatar
    Ralph Bankston

    Brent deploying code does not run chef recipes and is taken care of through the Apply mechanism. It is separate from the chef recipes.

Please sign in to leave a comment.

Powered by Zendesk