How to update your AppFog app with ZERO downtime

As those of you who have deployed apps on AppFog may know, when you’re updating an app (most likely using a simple af update <app-name> command with the AppFog Ruby gem), you tend to confront downtime during the deployment process. The AppFog update process involves stopping your app, then re-staging and re-starting. Obviously, for some of you that downtime is problematic.

Here’s how we suggest deploying apps without any downtime, and with the added benefit of being able to roll back quickly if there are problems.

Let’s say your app, called AppFogFTW, is running on AppFog at (that’s a mouthful!).

1. Deploy identical versions of the app: appfogftw at and appfogftw2 at Here’s what the two apps will look like in the CLI if you run the af list command, which lists all of your currently deployed apps.

| appfogftw    | 1  | RUNNING |,
| appfogftw2   | 1  | RUNNING |

2. Develop your app at appfogftw2, deploying new code until you are ready to make a push to That way it can potentially have 404 errors while updating but your users won’t see them. Run a normal update:

af update appfogftw2

3. When you are ready to push to production, first map appfogftw2 to and, and then map appfogftw to

af map appfogftw2
af map appfogftw2

4. Now, you have two applications running at the same URL (appfogftw and appfogftw2) and they are load balanced. You can use this time to test appfogftw2 in production if you like.

| appfogftw    | 1  | RUNNING |,
| appfogftw2   | 1  | RUNNING |,,

5. Finally map appfogftw to and unmap appfogftw from and

af map appfogftw
af unmap appfogftw2
af unmap appfogftw
af unmap appfogftw

6. If there are any troubles with appfogftw2, rollback is trivial. You just map appfogftw back to Users will never see any downtime and you can rollback easily.

| appfogftw      | 1  | RUNNING |
| appfogftw2     | 1  | RUNNING |,

7. Now you can develop against appfogftw (instead of appfogftw2) and when you are ready to deploy to production, you can reproduce the same steps as above.

af update appfogftw

And that’s it!

If you have devised other ways of implement zero-downtime updates, please share any tips here in the comments. Happy updating!

Share this post
Facebook Twitter Google
Try AppFog: The new PaaS Hackers love
  • Halil Özgür

    Automated versions of this would be useful, though since Appfog is multi-platform (e.g. unlike PHPfog) I assume there would be many ways for each platform. Yet a few automated tools regarding this would be useful in this area.

    Examples could be deploying the new version to a temporary place, testing it, and refusing the deploy if there are errors. You probably have already guessed that the example is taken from ROR world :)

    But such thing at its current form wouldn’t work for other platforms, e.g. for PHP since obviously there is no compile step. Nonetheless, I think at least a pre-commit hook which does some of the things mentioned at would be very useful.

    Testing different platforms, some compiled and some interpreted would have very different implications. Still I hope we have more and more options in automated and continuous deployment.

  • M G

    what are the valid values for debug mode? eg “af update myapp –debug [MODE]” ?

  • esseti

    well, if the app uses the db, this method will not preserve the data in the database as long as both app shares the same db (that seems to be unlikely since one si for dev). am i right?

  • Jasdeep Khalsa

    I’m sure it would be pretty easy to bake a quick shell script which takes the apps and urls as parameters and a few simple commands e.g. ‘–loadbalance’, ‘–live’, ‘–dev’. If you think a script like this would be useful email me and I’ll be happy to write one and open source it!

Powered by Olark