This guide assumes that you have already signed up for an Engine Yard account. If you have not yet done so, go ahead and get started now at Engine Yard Cloud.
Application information
When you first sign up, you need to configure your first application.
We need to have your Git Repository URI to checkout your code and deploy it to the instance. If you are using GitHub, you can find your git repository URI by:
- Clicking the drop-down for 'code'
- Click SSH, and then 'copy to dashboard' button (see outlined button below)
Note: It is important to select SSH when referencing a private repository;
We will try to guess a good name for your application from the git URI. If we choose poorly, please enter a better name.
Application Type: Select the framework your application code uses. If you don’t know which framework to select, ask the application developer. If you used the sample ToDo application, select Rails 3. Engine Yard Cloud sets default configuration values for you based on the framework you select.
Tip: Most modern applications work well by selecting Rack, including Sinatra and Rails 3; simply select Rack and everything will work. If you are using an older framework, please select the appropriate one.
Set up a git deploy key
If you use a private repository, set up your git deploy key. Engine Yard automatically generates a deploy key for applications with private repositories.
To set up a git deploy key
-
On the dashboard, application page, click the Deploy Key link.
The Git Deploy key appears for your application.
-
Copy the git deploy key.
-
Add the git deploy key to your github repository.
See github:help for how to add a deploy key.
Environment information
Next we need to ask a few questions about the environment where your application will run.
For help completing this page, see Environment options.
Boot your environment
The final step is to select the servers you need to boot for this environment.
-
Single Instance: If this is a staging environment without strict uptime requirements and you don’t expect to grow in the future, select a single instance environment.
-
Staging Configuration: For non-production environments, a staging config gives you room to expand in the future and also allows us to implement takeovers if your application master server goes down.
-
Production Configuration: For production environments, the production config is recommended. It provides for future app growth and includes a database replica (slave) in case your database goes down.
-
Custom Configuration: If your needs cannot be met by the pre-configured options above, select custom config to suit your unique environment.
Where to go from here
You can set up various Internet and networking technologies.
Learn more about the different types of instances available to you, including application, utility, and database instances.
If you have feedback or questions about this page, add a comment below. If you need help, submit a ticket with Engine Yard Support.
Where is the 'show deploy keys' page? Has it moved?
Hi Tom,
From your Dashboard, click on the Application name directly (not the environment name). Toward the top just above the edit link you should see a "Deploy Key" link. Clicking that should show you an overlaid text field with the deploy key for that application.
Hi Tom, Thanks for pointing this out. We've modified the wording to make it clearer. We appreciate your feedback to improve the docs.
Thanks, J. Austin! kjm
I would be nice to document the effect of the "Application Type" option here. What does it do? Are "Rails 3" and "Sinatra" actually equivalent? Are they equivalent to "Rails 2"?
What is the effect of changing an existing app from "Rails 2" to "Rails 3"? If they are all equivalent, I suggest including only "Rack" and adding instructions that Rails 3, Sinatra, etc, should choose Rack.
Hi Chris, Thanks for your suggestions on this doc. We've updated the Application Type description above. I also asked one of our developers for more info and here's what he said:
"So app type does a few things depending on what you've selected. This usually boils down to things like setting different configuration values, or adding different hunks of configuration to different places.
Now these days, rails3, rails4, sinatra and rack are all pretty much synonymous with each other. They all use the 'rack' interface, but are in the interface for an attempt at clarity ... Rails2, merb, nodejs and php activate a bunch more 'stuff' in the configuration run. Perhaps the takeaway is that for most modern applications, choosing 'rack' is the most reasonable choice."
So although these days Rails, Rack, etc. are pretty much equivalent, we still have customers with legacy apps that need the other choices available to them.
(Also updated this doc to reflect the new production cluster option.)
Thanks again for your feedback! kjm
from where i have to install rails on server
Hello Testsite Testsite. If you add rails to your Gemfile our system with bundler will automatically install rails on your server for you. If you need additional assistance please feel free to open a ticket for more information.