Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 7 years ago.
Improve this question
A little about myself. I am 24 years old, I graduated from NC State with a Master's in Analytics last year. Statistics, mathematics, that kind of thing. I don't have a strong programming background, which is pretty important for my question. If I say anything that doesn't make any sense, that is why. Ever since graduation, I have been working full time on a Rails app with a few other people. My programming experience is mainly Ruby on Rails (1.2 years.) I know R, SAS (statistical languages, not helpful for this question.)
Obviously, that means it has been over a year in development, and we aren't done yet. The main developer is an excellent programmer, just that he has a full time job already, and does this app in his spare time. Due to him not having enough time recently, I have been given practically full responsibility for the app.
We have it deployed on Slicehost right now. The app is at a point where we don't need to program anything else (unless we think of more features.) The reason I am asking if we should migrate to Heroku is that it seems to me that Heroku is a simple platform to which to deploy. Slicehost seems too complicated for me. The other developer dealt with it, and not me. I looked at how to deploy the app on Heroku, and it looks like I would be able to do it. We need our app to scale if it needs to, which Heroku offers. As far as money, I would start it at the minimum (free) and see how it goes. I can pay for additional features if I need to.
We are using Redmine for project management and repository (not git, which I think we need to use on Heroku.) Is git similar to Redmine? Is it easy to use?
Right now, on Slicehost, we have 4 daemons (constantly running processes.) We have 8 delayed_job workers. I know the command line to start the daemons and delayed_job workers. Would these work on Heroku?
I am wondering if I can still use RAILS_ENV=production script/console with Heroku.
The user interface is a javascript file. In development mode, if I do script/server in a terminal, and go to http://localhost:3000 in a browser, I can see it. Would Heroku load this page the way I want?
We have a working website for the app, with our own domain name. I don't really know what DNS is, so I probably wouldn't be able to link the Heroku app to it, unless there is an easy way. I think Heroku links it to appname.heroku.com as a default.
Based on my programming experience, would Heroku be easy enough for me to use, should I find another job, or should I commit seppuku?
Yes, you should definitely deploy your application in heroku. To do this, this is what you will need to do:
Make sure you have git installed in your computer
Create a heroku account here
Install the heroku gem and do the rest as mentioned in this page
Track your application with git, and create your heroku application as shown here
After you do this, heroku will provide you with a URL for your application, such as http://blah-bleep-123.heroku.com. Now, the next step would be to associate your domain to this heroku URL.
Configure your domain DNS Server as shown in this page. Mind you, after you change your DNS, it might take upto 48 hours for it to work. You can change your domain DNS by logging into the site where you bought your domain, for e.g. godaddy.com, hostingdude.com, etc.
Add this code to your ApplicationController. You can follow this from this page as well
class ApplicationController
before_filter :ensure_domain
APP_DOMAIN = 'www.mydomain.com'
def ensure_domain
if request.env['HTTP_HOST'] != APP_DOMAIN
# HTTP 301 is a "permanent" redirect
redirect_to "http://#{APP_DOMAIN}", :status => 301
end
end
end
Make sure you migrate all your database in heroku, by doing heroku rake db:migrate
After you have completed all these steps, you should be good. Check out your domain URL, everything should work pretty :).
If you see any errors in your page, you can view the log by heroku logs
You can access console as heroku console
With features as these, heroku is very convenient to work with.
Please let me know if you need more help.
It seems to me like you should seriously consider Heroku. I have used it for weekend projects and we use it at work as well, quite successfully. Deployment is a breeze, you don't have to worry about setup (for the most part) and system administration. It's super easy to add modules and "pay as you grow".
As for your needs, you could (I believe) run your redmine on Heroku itself, being a rails app. The only thing is that you mention you use Redmine as "repository" and I'm not sure I understand what you mean, since Redmine is not a version control system. Redmine has integration points for various VCS (SVN, git, Mercurial, CVS, and others). Yes, Heroku uses git and that is what you would need to use in order to push code to the server. If you're familiar with Mercurial, it's pretty similar.
For delayed jobs, Heroku offers free cron jobs that run once a day and hourly ones for a fee (see cron add-on). There is also a delayed job plugin (see this) but I don't have any experience with it.
You should be able to access the Rails console (see heroku docs). Just run 'heroku console' and voila, you're there.
If your app works by running script/server, it should work out of the box in heroku too.
As for the DNS, getting it to work with your custom domain is not hard. Out of the box, you can access your app with appname.heroku.com, to set up your custom domain check heroku docs here, but basically you have to add the custom domain add-on (free unless you want subdomains), configure heroku to respond to your domain's requests (couple of simple commands) and set your DNS provider to point to Heroku (there's even a short video in the docs on how to do this with GoDaddy).
The only drawback I've seen with Heroku, and it's not a huge one, is that if your app does not receive any traffic for an extended period of time, the instances kind of "go to sleep", making the next request to arrive somewhat slow (sometimes even timing out), but once the instance is awake, everything is good to go.
All in all, I think Heroku is a great way to take a ton of the burden off of you as a dev and making a lot of things really easy to implement without having to go into the nitty gritty of setting up a server. The downside: once you start growing, it can become somewhat expensive, but hey, if you're growing it probably means you have the cash now to hire someone that can take care of the nitty-gritty.
You might also want to take a look at this blog post which compares Slicehost and Heroku
Best of lucks
YES, go for it.
If you've managed thus far on the strength of your 'programming experience' then you'll be fine. Have some confidence and ship something! To quote Paul Graham:
The reason to launch fast is not so much that it's critical to get your product to market early, but that you haven't really started working on it till you've launched. Launching teaches you what you should have been building. Till you know that you're wasting your time. So the main value of whatever you launch with is as a pretext for engaging users.
The functionality you outline is easily replicated and well documented and it's free to start with. What else could you ask for?
If you have the free time, you might as well sign up for a free account and give it a shot.
HOWEVER, this is going to come with some pretty severe headaches.
Version control will be one, since heroku uses git, but another one that no one's mentioned yet is that your 12 processes ("dynos" in heroku speak) would cost you $35 * 11 = $385 per month! You can set up an hourly cron for $3/month that will flush your delayed_job queue (instead of having workers running at all times), but is that going to be adequate? (If you're running 8 workers, I'm guessing not). This may or may not require some code changes.
Once you get it set up, deployment and admin is really easy (nonexistent), but it'll cost you if you start needing new features.
YES, go for it.
Its good deployment environment any its fast and easy scale out and scale in feature.
even you can use for your testing or demo usage its provide you free account usage of 1 dynos per app.
List of add-on tools available you can add as per your requirement.
Related
I am about to deploy my 1st Rails app. I am stuck as I don't know what exactly I need to do. I know about Heroku, AWS, Capistrano and the like, but don't know exactly what they do, and what their benefits are.
I kinda know some things, but all are blurry and ambiguous since I have no formal training and learn as I go. So basically I need someone to explain the general anatomy of Rails deployment.
Something like: 'To make any app working on the web you need the following components... Ways to make this component work with Rails are following. Alternatives are these. These are pros and cons.' Not into too much detail, but general and comprehensive 101 guide.
The reason you may be confused is that there are a number of ways to do it. :D
Heroku provides one of the easiest solutions for basic deployments. You don't need capistrano, just git. (they provide a toolset to assist). Just git push heroku master. Also nice is that a simple deployment on heroku is free; you can pay for more power when you actually need it.
But if you need a little extra functionality that heroku can't provide, you have to host elsewhere, such as a private virtual host.
Capistrano is a set of recipes that help build a deployment environment, sort of like rake tasks. It does so in a very organized manner and allows for easy rollbacks. You define the hosts, their roles, and then the recipes use ssh and scp to set up the evironment. (the server also has to be ready to accept rails applications, through something like passenger)
The Rails and Ruby World(s) are pretty noisy, so I understand your confusion.
At the end of the day, you need your rails app on a server.
Now, even the term server can be a little confusing, because it is generally associated with
A remote machine
A program handling HTTP requests.
(for example webrick or thin which you start when you are developing on your computer and type rails s)
In your case you actually want a remote computer (hooked up to the net) which is running a program called a server to process HTTP requests and forward these to your app which in turn produces a request...
Heroku will help you out with that. (However Heroku adds several layers of abstraction to the mix. So it is not like you have one computer sitting somewhere in the heroku office, serving your application.) Heroku is dead simple to setup with git and rails.
And in the end all that is need to get your app to the "remote server" is a simple git push.
Read the beginner articles on https://devcenter.heroku.com/
I would also suggest for now: Forget about Capistrano.
Oh and you can think of AWS (or probably S3) as some sort of external hard drive, which your app can use to store larger pieces of data (like images, videos etc.)
I have a deployment guide with a good shell script which support Nginx + RVM + Unicorn: deploy_rails
Just wondering how everyone pushes updates to their production server on Heroku, without bringing the app down for a few couple of seconds?
Pushing to Heroku (especially using something like Unicorn), takes a while for the web app to load. Especially when there are end-users trying to access the site. They end up with 503 pages.It takes up to 30 secs to a minute for Unicorn processes to load.
There are TWO things you need to accomplish this, and it's not trivial.
1) Migrations need to be backwards compatible (i.e., run while the app is live). See this article about that: http://pedro.herokuapp.com/past/2011/7/13/rails_migrations_with_no_downtime/
2) Deploy using TWO heroku apps. I opened a ticket with Heroku on this topic and this was their reply:
We're currently working on a solution to provide a zero-downtime
deploy but do not have an ETA on when this might be available.
In the meantime a workaround that might be possible would be to deploy
to two separate apps. You can push new code to the second app, spin it
up, then move the domain names over to the second app. Wash and repeat
on the next deploy. This is less than ideal but might get you the
desired result in the interim.
If you do this, you will want to automate as much as possible since there's a lot of ways to mess that up. Here's an article on that topic: http://casperfabricius.com/site/2009/09/20/manage-and-rollback-heroku-deployments-capistrano-style/
Why?
These two solutions must both be done because the database migrations must work in BOTH (live and to-be-live) versions of the code. Once you have that working, THEN you can solve the second problem of having the application itself not seem like it went down. There is no supported way to spin up and spin down individual dynos once a push is started.
UPDATE:
There is a beta feature available with Heroku now. To use do the following prior to pushing:
heroku labs:enable -a APP_NAME preboot
This will change the behavior of the app during pushes. It will push up a parallel instance that will warm up for two minutes. Almost exactly two minutes after the push, all traffic will route to the new app. Be careful with migrations, as I mentioned above, as they are still an issue.
Heroku is currently testing their new preboot feature in beta. You might wanna check it out. Unfortunately it only works for ≥2 web dynos. And it also doesn't seem to work for heroku scale web=… which would be important to make it work with HireFireApp.com.
Is it possible to do something like the Github zero downtime deploy on Heroku using Unicorn on the Cedar stack?
I'm not entirely sure how the restart works on Heroku and what control we have over restarting processes, but I like the possibility of zero downtime deploys and up until now, from what I've read, it's not possible
There are a few things that would be required for this to work.
First off, we'd need backwards compatible migrations. I leave that up to our team to figure out.
Secondly, we'd want to migrate the db right after a push, but before the restart (assuming our migrations are fully backwards compatible, this should not affect anything)
Thirdly, we'd want to instruct Unicorn to launch a new master process and fork some workers, then swap the PIDs and gracefully shut down the old process/workers
I've scoured the docs but I can't find anything that would indicate this is possible on Heroku. Any thoughts?
I can't address migrations, but the part about restarting processes and avoiding wait time:
There is an beta feature for heroku called preboot. After a deploy, it boots your new dynos first and waits a while before switching traffic and killing the old ones:
https://devcenter.heroku.com/articles/labs-preboot/
I also wrote a blog post that has some measurements on my app's performance improvements using this feature:
http://ylan.segal-family.com/blog/2012/08/27/deploy-to-heroku-with-near-zero-downtime/
You might be interested in their feature called preboot.
Taken from their documentation:
This feature provides seamless deploys by booting web dynos with new code before killing existing web dynos.
Some apps take a long time to boot up, and this can cause unacceptable delays in serving HTTP requests during deployment.
There are a few caveats:
You must have at least two web dynos to use this feature. If you have your web process type scaled to 1 or 0, preboot will be disabled.
Whoever is doing the deployment will have to wait a few minutes before the new code starts serving user requests; this happens later than it would without preboot (but in the meanwhile, user requests are still served promptly by old dynos).
There will be a short period (a minute or two) where heroku ps shows the status of the new code, but user requests are still being served by old code.
There is much more information about it, so refer to their documentation.
It is possible, but requires a fair amount of forward planning. As of Rails 3.1 there's three tasks that need carrying out
Upload the new code
Run any database migrations
Sync the assets
Uploading code and restarting is fairly straightforward, the main problem lies with the other two, but the way round them is the pretty much the same.
Essentially you need to:
Make the code compatible with the migration you need to run
Run the migration, and remove any code written specifically for it
For instance, if you want to remove a column, you’ll need to deploy a patch telling ActiveRecord to ignore it first. Only then you can deploy the migration, and clean up that patch.
In short, you need to consider your database and the code compatability an work around them so that the two can overlap in terms of versioning.
An alternative to this method might be to have two versions of the application running on Heroku at the same time. When you deploy, switch the domain to the other version, do the deploy, and switch it back again. This will help in most instances, but again, database compat is an issue.
Personally, I would say that if your deployments are significant to require this sort of consideration, taking parts of the application offline are probably the safest answer. By breaking up an application into several smaller applications can help mitigate this and is a mechanism that I use regularly.
No - this is currently not possible using Unicorn on Heroku cedar. I've been bugging Heroku about this for weeks.
Here was Heroku Support's reply to my email on March 8, 2012:
Hi, you could enable maintenance mode when doing a deploy, at least your users would see a maintenance page instead of an error, and also request queue wouldn't build up.
We're definitely aware this is a pain and we're working to offer rolling / zero-downtime deploys in the future. We have no ETA to announce, though.
I have been hosting a site on Heroku for a few months that is very soon to go into production.
Since I began with them, there have been at least three significant outages, one of which was the disastrous Amazon outage last month and another of which is a multi-hour outage happening today.
I believe in Heroku's vision and I think they are a great company, but I am faced with the ultimate problem: if they can't keep sites up and running, everything I like about them doesn't really matter.
Is Heroku a reliable provider to run a production site on Rails?
Are there any other providers I might look into that have a better reputation for reliability than Heroku?
In my opinion, downtime can happen with almost any provider. What you need to see is how well or badly the host handles the downtime and the effort they make in keeping the customer updated about possible resolution.
In my opinion Heroku is a great place to host your app. The advantages and ease of deploying there covers up for the recent (and rare) downtime FOR ME.
I am user of Heroku with Amazon RDS plugin for the past 7-8 months and my conclusion is there is nothing to appreciate about Heroku except their architecture. Here is why I think:
Even though it is sold for $250 million+ they were still NOT using the Amazon multiple zones feature of Amazon. Below is the link how SmugMug survived amazon crash by using Amazon's multiple zones feature.
http://don.blogs.smugmug.com/2011/04/24/how-smugmug-survived-the-amazonpocalypse/
No phone contact support in the event of issues (not application but Heroku's), lot to learn from Rackspace
The application I am hosting, people will starve if it goes down for few hours on Friday forget about 60 hours downtime.
I see intermittent deployment and connectivity issues. Please visit this link for a confirmation:
http://status.heroku.com/
I know developers love it because they throw a cheap web process called 'dyno' for free.
So far Heroku does not offer multiple availability zone redundancy. If you want something more reliable than Heroku you can create your own EC2 instances in multiple availability zones. Of course this will require significantly more server upkeep, admin, and deployment time.
I have seem Heroku to be reliable. I highly recommended it for starting out and validating your idea. I believe when you start your project you want get it out quickly (to customer or to public).
As mentioned in other comments at some point you might need to switch over to EC2 as you might need zone redundancy and it might actually become cheaper to run of EC2 especially if you already have an SA in the company.
No. It is not. As a customer I've experienced multiple critical outages. These things happen and I get that. But what makes Heroku unreliable is their nearly non-existent support when things do go wrong. I would use caution when evaluating Heroku or any provider for that matter and really understand what you're paying for. Paying as much as I did for Heroku I expected more.
As an example one of their databases went offline early on a Sunday. I immediately was made aware, not from Heroku but from our customers and new relic alerts. I contacted Heroku support just to get the ball rolling as I began to troubleshoot. 24 hours later I had literally no responses from Heroku. I could not fork, follow, or take snapshot of the database as they suggest (because they were experiencing issues) so I basically sat on my hand and waited. Hoping that somebody would respond as I frantically attempt to recover somehow, someway.
Was this their fault. No. Not at all. I should/could have done something to mitigate this failure. But as much as I pay for their servies each month I expected something resembling a response to my critical issue.
Our our app is hosted by Heroku and went down mutliple times over the last 12 months.
Two times it was caused by one of the third-party apps that Heroku offers:
We used Zerigo (recommended by Heroku) for our DNS. This has caused our site to go down twice - one time it took over 12 hours te recover. This is absolutely crazy for something like DNS, so we have switched to a more reliable provider.
The Redistogo app went down once.
Heroku does bring some benefits, but be careful about the apps you select.
In my org i build simple SPA productivity apps, and have been using Heroku to host them for the last year after migrating away from a physical box server to cloud VMs.
I've had multiple days lost due to Heroku development hindering outages. Usually while running apps stay online, and work, when Heroku goes down you can't push updates or restart apps.
Lets also not forget the ridiculous times for scheduled maintenance (usually 2PM EST, midweek....REALLY?)
As of writing this, the Logging system for Heroku has now been acting up (more or less down) for over 24 hour.
Thankfully my apps aren't mission critical. While I like Heroku's ease of use, it's just not worth this much headache for what is nothing other than an AWS middle-man.
That said, I'm moving over to just pure AWS EC2 instances.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 9 years ago.
Improve this question
I'm close to picking a Rails host. I think I need a VPS solution, because (1) my Rails app has gems and plugins that I need to install to get it working, and (2) I need an SMTP server to send emails from my rails app out to users.
But then it occured to today...
1) Do I actually need VPS and root access to get my app up and running, just because I need to install gems, or can I just copy my Rails app folder up to a Rails-supporting hosting server and start it?
2) If I get a Google Apps account, which would include a business-class GMail solution, would that give me an SMTP server which I could use to send emails to users?
I'm looking for least-support-needed-solution. I can afford to pay for VPS hosting, and a Google Apps account, but I just wonder if this is really my best option.
UPDATE: It's now been just over three years since I first posted this question and answer. I still prefer AWS for all new deployments of a professional or serious horsepower nature (that is, if I don't self-host), but I also regularly deploy demo and tutorial apps to Heroku. I haven't tried any of the many VPS providers that have popped up such as Linode or DigitalOcean, but generally hear good things about them.
The key thing that keeps me from choosing Heroku for all my apps is cost. Since most of my indie projects outside of work are things where I'd prefer to absolutely minimize costs, AWS remains the better deal between AWS vs. Heroku. AWS (or any VPS provider for that matter) has the nice side effect of teaching you the OS along the way, which turns out to be hugely valuable in the long term.
=======================
So, two years later, here's my update. I've used three services for hosting, and here's my take on each of them (I actually love them all, but for various reasons).
Slicehost (now part of Rackspace Cloud Hosting)
This was the first VPS host I tried, and I loved them. The people there were amazing, support was awesome, and it had a really cool grassroots kind of feel. Now that VPS as a solution is more mainstream, and Rackspace has long since purchased Slicehost, I feel that the service offering is still awesome. If you want a simple way to setup a server, plenty of Linux distro choices, and control over your server, this is an awesome option.
Heroku
Love these guys too. I built a hobby app that is hosted there, rpglogger.com (which as of Nov. 2012 has actually migrated to Amazon Web Services), and developing and deploying to Heroku is a no-brainer. I really like working on Heroku for two reasons:
It's dead simple to setup. It really is as easy as they say, in my experience, to get an app running on their platform.
A single dyno (web server instance) is free. So hobby apps, and smaller apps basically get free hosting. It's not just for hobbies though - their plugin architecture is second-to-none, making the addition of 3rd party plugins such as NewRelic, Exceptional, and anything else on their platform a matter of just a few clicks.
You absolutely cannot beat Heroku for ease of use. Deploying an updated version of your app is literally as simple as pushing to your git repo. Heroku isn't necessarily cheap (for anything other than the small app), but if you're in a situation where you believe developer time is more valuable than having control over the server, then this is an amazing option. You can always migrate your app to any other platform anyhow, if it gets big, or the needs of the app vs. the cost of Heroku no longer make sense for you.
Amazon Web Services
I do quite a few small apps, and AWS reserved instances are awesome. For $60 I can basically get a reserved instance for an entire year. That one server is enough to run 3-4 small apps on the same machine, with more optimized memory usage, and the ability to run multiple web server instances (vs. Heroku's one free dyno, though I hear you can custom config your Heroku dyno using unicorn to get more scalability). Basically, AWS scales really well, and lets you share a server among multiple small apps, or spread a larger app across multiple servers.
On top of that initial cost for the reserved instance, I only have to pay for bandwidth and other AWS usage (S3, for example). I think AWS is an amazing mix of ultimate scalability, great costs, ultimate control, and for enterprise customers who want to build their entire infrastructure in the sky, it can't be beat. Rackspace Cloud Hosting provides similar services, and they're probably comparable for most things. But if what you want is the Swiss army knife of cloud services, I think AWS is still way ahead of everyone else.
===============
So, that being said, I started on Slicehost, then went to AWS, then tried Heroku, and today I spend most of my time back on AWS.
AWS is the kind of platform that, after you invest a little time in setting up your collection of VPS machines, it often makes sense to stay on this platform and leverage their ever increasing set of tools.
Granted, it took me two years of trying several options, and trying every level of management from fully managed servers (i.e. Heroku, where you don't even think of the server, just the app) to fully controlled servers (Slicehost and AWS). After all that I've come to this point where I'm ready to manage my own machines in order to get the flexibility and low costs that I want.
Through automation, the actual management of the servers on AWS becomes a non-event, so I don't spend my time constantly patching my machines, or doing other sysadmin tasks. I just check periodically to see if my servers need reboots, I set them to automatically install all security updates (I happen to deploy to Ubuntu servers), which means I spend 99% of my time (at least day-to-day) writing the application - not managing the servers (managing services is instead an occasional task of a few day's work, and then nothing else for months) - which is where I want to spend my time as a developer.
Neither of your requirements are VPS-specific. I use shared hosting from Site5 and currently run two rails apps through the account, both with gems that are not installed on the server by default and sending email. Installing gems does not require root access.
If you want to use a VPS anyway, both Slicehost and Linode are often recommended for Rails apps. A few more are listed under Deploy on the Rails site. I would encourage you to do some research on your choice in either case. Good luck!
You could check out Ruby on Rails Hosting, What is a good Ruby on Rails hosting service?, Good Ruby on Rails free hosting, and What is a good Ruby on Rails and PHP hosting?.
I personally prefer Heroku which has offers free low-scale hosting and is very easily upgraded. Also, they allow you to install gems (similarly to the gem dependencies and rake gems:install, but with different syntax/files), and send a few free emails (200, but it is easily upgraded).
I hate Heroku, it gives you no control over services you want to use and it's massively over priced. Just try to make use of a gem or service they don't specifically support and you will quickly find the limitations and the horrendous pricing.
Heroku is my host of choice.
You can send messages using GMail SMTP as well as the commercial SMTP plugin.
I have also used Slicehost, Linode, Dreamhost and RailsMachine.
Slicehost/Linode are awesome if you can set up the box yourself.
Dreamhost is cheap-as and great for staging. Sites are ponderously slow at times though.
RailsMachine is second to none as a managed service. Highly recommended for the support and the well-tuned stack.
I prefer linode, aws or so.
linode : is a standard linux server. you can login, install 3rd party dependencies and play around just like in your own server. Installing nginx/rails/ruby is the same way as what you did on your own pc/laptop/server.
heroku : is a service. I have to learn lots of stuffs that are not valuable at all if one day you switch to another platform(e.g. linode) or you have your own real server, for example, check the logs, install databases, or install gems. I have printed out most of its documents and read them in 1/2 days, and then I realize that I can't use these knowledges in my working server( that my company offered to me)
linode is cheap enough, $20 per month.
heroku is not always free. and I don't think it's stable enough for demonstration purpose.(e.g. your free heroku app will fall in sleep in spare time, and will cost you several seconds to wake up. this SEVERAL seconds is long enough to make you lost your customers if they want FAST web app )
so, forget heroku, buy or setup your own VPS, use it for years, then you will be an linux expert.
I use HawkHost for all my hosting needs, and I'm 90% sure they meet all your criteria. They provide web hosting and VPS services for very good prices, and their basic web host plan lets you have Rails applications running as well.
I'm used Joyent host- http://www.joyent.com. It's good Rails host.