Introducing Blueprints

Blueprints have been a long requested feature on Engine Yard Cloud, but what exactly are they?

In the case of Engine Yard Cloud, a Blueprint is a way to describe an instance configuration for an environment, including the number, flavor,and volume sizing for all application, database and utility instances. This allows you to easily recreate environments without going through the tedious process of filling out the Boot Instances form each time.

You’ll find the Blueprint Manager page in your Tools drop down on the Cloud dashboard. From there, you can view, edit, or delete any existing Blueprint as well as create a new one. You may also notice that you have some auto-saved Blueprints. When all instances in an environment are stopped, the dashboard will automatically generate a Blueprint for the current configuration and save it for you.

This is what a single Blueprint in the Blueprint Manager looks like:

A Blueprint can be selected when you want to boot instances on a new or existing environment. On the Boot Instances page, select Custom Configuration.

After that is selected, you’ll see a Blueprint drop-down and link to Manage Blueprints.

Select the appropriate Blueprint and the dashboard will auto populate the Boot Instances form for you. It’s that simple!

Here is what the Blueprint drop-down looks like on the Boot Instances page:

Keep in mind: Blueprints only control the instance configuration. This includes the sizing and total number of instances in your application, database, and utility instances as well as the volume sizes on each tier.

A Blueprint will not save your environment configuration, which includes things like: Ruby/PHP/Node version, database type and version, backup frequency and retention, and so on. You still need to create separate environments for purposes like differentiating staging and production, utilizing different region,s or testing out different stack components. Blueprints make it easy to replicate instance configurations whenever a new environment is created.

Blueprints not only save time, they also help track different configurations for a number of environments. Perhaps you have a standard configuration for your production environment during the holidays, that configuration could be saved as Blueprint.

Also, because Blueprints are automatically saved upon terminating an environment, you no longer have to worry about the size and number of instances you were running before shutting down that environment. A cloned environment can be easily shut down and brought back up using the last Blueprint with only a few clicks.

We are very excited about this feature. If you have and feedback about Blueprints, how you use them, or how they can be improved: please get in touch!