Once rubber is installed and configured for your project, the workflow is as follows:

1. Create instance(s)
2. Bootstrap instance(s)
3. cap deploy(:cold)
4. Rinse, Repeat

Since bootstrap runs for all roles/hosts, not just the newly created ones, I tried to make it safe for repeat executions on existing instances. However, you should probably verify that this is the case for your setup before trusting it on a production system.

Note that if you change a config file template, and are using a real scm provider for capistrano (like svn), you need to check it in before rubber:config will be able to see the change on remote hosts. One should use the noscm scm provider for capistrano to iterate rapidly when building out a deployment scenario with rubber. This is the default in the deploy.rb provided by the vulcanize generator.

I recommend that people use nettica for managing their DNS because they have a completely scriptable API for adding/removing instances from DNS which I have integrated into rubber (thats what I use). There is also full support for zerigo which does have a free plan for low usage account. There is also limited support for dyndns (basically any service that has a url for mapping hosts→IPs using basic http auth), but I don’t use it so no guarantees on how well it works.