Announcing New Regions!

2016 was a busy year for AWS, launching 3 new regions in the last quarter of the year. These regions are located in Central Canada (ca-central-1), Ohio (us-east-2), and London (eu-west-2). In order to provide our customers with the options that fit their needs the best, Engine Yard is happy to announce the immediate availability of these regions.

These regions are available when booting up an environment for the first time. Just select the appropriate option from Region dropdown menu when creating the environment. Engine Yard clients who have their own AWS accounts will also be able to provision resources in these regions in the exact same fashion. If you have any questions, please contact our customer success team.

Stable V5 Is Now The Default Stack

As mentioned in a previous announcement, Engine Yard has released our latest stack, stable v5. With many feature enhancements and stabilization in the past three months, we are thrilled to announce that we have made stable v5 the default stack for the Engine Yard PaaS platform.

Read More
Learn about Engine Yard
Try Engine Yard for your Ruby or PHP Apps

Building Rails Applications in Docker

Docker images can provide a powerful interface for deploying your Rails applications. Everything your application needs in order to run can be packaged inside a Docker image. The Docker images can then be deployed from your laptop, staging and to production. This greatly increases the parity between your development and production environments when making a Rails application.

Read More

Monitoring & Alerting for your app, Improved!

When you build, run, and scale an application, being able to monitor it and alert accordingly is a core need. At Engine Yard, side by side with our leading Platform offering, we do also include monitoring & alerting as well, with a Support Team backing it all up.

What do we watch for you

Our Platform monitors a series of indicators on each running instance, like CPU, memory, swap, and disk usage. Additionally, our Backend monitors events from AWS’s CloudWatch, including system level issues and CPU credits on t2 instances. When it comes to database instances, all of the above is included plus the monitoring of db specifics such as replication state, connectivity, connection limits, and the presence of long idle transactions.

Read More

Faster Database Transfers

Sometimes it becomes necessary to move your database from one environment to another. Common reasons for this include:

  • Updating a Testing or Development environment with Production data
  • Migrating from one stack version to another (e.g. Stable-v4 -> Stable-v5)
  • Upgrading to a newer major version of your database (e.g. MySQL 5.5 -> MySQL 5.6 or Postgres 9.2 -> Postgres 9.4)
  • Upgrading storage to Encrypted EBS
  • Upgrading the filesystem to EXT4

The traditional method involves three database related steps:

  1. Creating an on-demand backup in the source environment.
  2. Downloading the most recent backup in the source environment.
  3. Transferring and Restoring the backup from the source to the target environment.

This results in some time and processing inefficiency since using eybackup uploads the backup to s3 and then it needs to be downloaded as a separate operation. For a small database this works just fine; unfortunately, for large databases this extra step could add hours to your migration plan. A better way to approach this would be to use the database-native backup tools to backup the source database to a file, and then transfer that file to the destination for restore.

Read More


Look through our specially curated posts to get focused, in-depth information on a single topic.