About Instances on Engine Yard Cloud

Instances on Engine Yard Cloud comprise of the compute resources that are dedicated to running your Ruby application in the cloud. Instances can be configured to serve your application tier, database tier, cache tier, background processing and utilities, and more. Instances are available in various configurations to meet your CPU, memory, and disk space needs.

Engine Yard Cloud is built on top of Amazon’s AWS services. When you create an instance with Engine Yard, you are booting up an EC2 instance. We boot this instance for you and automatically configure it with the appropriate Engine Yard stack components for your environment.


Persistent storage

Your application code and database are written out to persistent storage volumes. We automatically mount these volumes and take backups for you.

Both the /data mount on the application master instance and the /db mount on the database master instance(s) are persistent. We take advantage of Amazon’s EBS storage allowing us to take regular disk snapshots of both of these volumes.

If you ever have to rebuild your instances from scratch you will have the ability to restore both of these volumes from previous snapshots.

Instance Types and Roles

There are various roles that an instance can play in your application’s environment. These roles include the following:

Application Instances

These instances are configured to run your Ruby-based application. They are configured with the Engine Yard stack. Your application is automatically deployed onto the /data mount which is persistent storage.

We back up the /data volume only on the application master instance.

You can run crons on your Application instances and you can setup crons to run on the application master instance via the web UI’s Crontab page. If your crons are CPU or memory intensive, consider off-loading the work to a utility instance.

Database Instances

This instance is configured to run your database. Running your database on a separate server prevents your database and application from contending for the same resources.

Your database resides on the /db mount. This mount point is persistent and can be used to restore your database later. We take regular snapshots and backups of your database by default.

Note: If your application does not use a database, or you want to use an add-on database instead of PostgreSQL or MySQL, choose the "No Database" Database Stack option.

For more information about databases, see Manage your database. 

Utility Instances

Utility instances are great for off loading any heavy work from your application instances. It’s common to run background jobs, job queues, and crons on utility instances. They are also useful for running large memcached instances.

We automatically push your code to the utility instances with each deploy for you. This allows your crons and background jobs to access any application code that they need.

Single Instance Environment

Single instance environments, commonly called a solo instance, are great for staging and development environments because they’ll save you money. You can boot up a single instance, and we’ll deploy both your application and your database to this instance. These types of environments are not, however, ideal for production because your database and application contend for the same system resources.

If you boot up a single instance environment to start with, you can upgrade it to a multiple-instance environment later.

More information 

For more information about... See...
Adding instances to a cluster                                                       Add Instances to a Cluster                     
No database option                                                       Create an Environment                     
Application master instances application master glossary definition

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


Article is closed for comments.