Connect with your Customers in Seoul

Here at Engine Yard, we recognize the importance of data accessibility and the importance of Region availability. The ability to provision instances through the Engine Yard platform around the globe allows clients to target specific users in geographic regions. In today’s fast-paced digital landscape, latency becomes a huge issue, especially with target markets in non-US territories. With this in mind, we’re happy to announce the Seoul, South Korea AWS region is generally available to all our customers starting today.

This region opens up huge opportunities to companies and applications that have direct target market in the Southeast Asia and Korean peninsula. Now you can be as close as possible to your end users, lowering latency and avoiding data transfer woes that might come with datacenters much further away. The Seoul region has two availability zones, allowing applications to be redundant across the AWS region, as well as allowing for auto-heal between availability zones. The region will function similarly to how Engine Yard offers other regions, with built in database backups and snapshots taken and held for you automatically. The Seoul datacenter will also have access to a majority of the newest instance sizes available from AWS as well as VPC enabling for all clients. Pairing this with Engine Yard’s twenty-four by seven support, you can accurately reach your end users like you’re in their backyard, even if you’re on the other side of the world.

You can read more about the AWS Korea region here:

To access the new region, simply create a new environment in any standard accounts with VPC-enabled by default.. If you’re interested in creating a new account with Engine Yard, please send an email to Remastered

The Engine Yard website has gone through a lot of changes in our history, and I’m happy to announce another makeover.

To get the job done, we partnered up with our friends at Cloud City. We’ve worked with them before, and they really get who we are and what we do. From the Engine Yard side, we wanted to get broad input from across the business, and involved people from our support team, DBA team, engineering team, and management.

Our main goal was to make it easier for folks to sign up and get started.

A secondary goal was to make sure our messaging was clear that we are, first and foremost, a provider of operational tools on top of AWS.

We also wanted to address some popular misconception about the price of our offerings. Because when you compare Engine Yard like-for-like with other PaaS providers, we often provide the better value for money!

In addition, Engine Yard has been around for more than eight years, and right from the start we’ve had a reputation for community involvement and deep Ruby on Rails expertise. That’s such an important part of Engine Yard’s DNA, and we felt we could do a better job of communicating it.

Hopefully, our new website addresses all these things and more. And while I know some folks might love it, or hate it, or love to hate it—we are trying something new.

We’ve also taken the opportunity to name our mascot: Pat the Panda. Pat has been a part of Engine Yard for years, but sadly never had an official name until now. So expect to see Pat popping up around the site.

You can look forward to some follow-up posts on the new website design. In the meantime, we welcome feedback. So take a look around, and let me know what you think.

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

Introducing Our New API

A public facing API has been a much requested feature of Engine Yard Cloud. We’ve had this feature available for quite a long time, but this API has a number of drawbacks. Some time ago, we decided that it was time for something new. We call it the Core API.

Why do we call it the Core API?

Well, because this API presents an interface to the core of our product!

We have been using this internally for quite some time, and it has gone through a number of major revisions. Finally, we are happy with the stability and decided it was time to release it to our customers.

If you’re currently using our existing API, this one is a bit different but hopefully easier to use. We do plan to retire the existing API, however we don’t have a set date for retirement at this time.

We’ve written a Ruby gem, ey-core, that makes working with our new API a breeze. It’s an open source gem, and if you would like to make improvements, we welcome your contributions! Head along to the GitHub repository to get started.

The purpose of this post is to look at the API design and help familiarize you with the tooling we already have in place, as well as help you get started creating your own tooling if you desire.

Read More

Bring Your Own AWS Credentials to Engine Yard

Here at Engine Yard we're always trying to make your deployment experience easier: easier to provision instances, easier to deploy, and easier to manage your infrastructure. Historically, part of that process involved the creation of an AWS account specifically for your individual use. However, with more and more companies adopting cloud-based architecture, more and more Engine Yard clients already have their own AWS account; whether it be used for massive numbers of instances, or just for S3 storage. We've heard your feedback and we're happy to announce that you can now bring your own AWS account to our platform.

Read More

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.

Read More


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