Rails is not great for small projects. There I said it. The framework itself is ideal for coding small projects. Actually it’s not the size of the code, but the size of the audience. I find all the ‘scalability’ FUD rather ironic, because Rails was designed to scale up. It’s scaling down that’s a problem.

Over the past 5 years, dynamic sites have become the norm. This places a drain on resources. These days, a single user can bog down a shared server simply by setting up a WordPress blog with a few too many plugins. But running PHP or Perl scripts with a MySQL back-end is largely a solved problem. Rails re-ups the ante by requiring memory-resident dispatchers (minimum 30MB a piece) to exist for each website.

Why is this a problem? Because the Basecamps, Odeos, and Alistaparts of the world are the exception not the rule. In my personal experience, the $1000-$2000 website is a sweet spot where a freelancer can find a lot of clients and churn out sites pretty quickly. Rails is ideal for this from a development perspective. But when it comes time to host many small Rails sites the options run thin. If they are a low-traffic, low-diskspace client (as most inevitably are) then it’s hard to justify a high hosting fee. If they were running some PHP application with low traffic then you could cram 100 clients on one shared hosting account without any trouble. However, if you try to put 100 Rails apps on a shared Dreamhost account, it will be swap city and you’ll probably soon receive a semi-friendly email from tech support.

Okay, so the solution is to require each client to have their own hosting account. Problem solved right? But I think there are larger implications for shared hosts running Rails. Managing load on shared hosts is a major issue, and Rails memory usage adds a new variable to the equation. Every other component of a web / database server can be memory-tuned, thus confining load management mostly to CPU usage. However, giving customers the ability to run Rails means a huge variance in the amount of memory consumed at any given time. Memory bottlenecks can lead to nasty feedback loops with disk contention and other sysadmin nightmares. In the beginning this was more or less a non-issue, because only a handful of people were using Rails. But with the proliferation of open-source Rails apps like Typo, even Joe-webmaster has the potential to run Rails and make life hell for shared hosts everywhere.

This touches on the topic of a future rant, which is that quality shared hosting is near impossible to find. The problem is that the market is driven by checklists and quantities, even though the most important thing is actually qualitative. Managing shared web servers is an art. None of these fly-by-night WHM/Cpanel startups have the talent to deal with issues that arise from overloaded shared servers. The best they can do is increase or decrease the number of users per server.

Serious Rails developers on shared hosting will be the catalyst that changes the industry. For those of use who can’t afford to go dedicated we need reliable shared hosting. With the rise of Rails, numbers like $5 for 10,000GB become even more irrelevant than they already are—if you’re pushing 10,000GB shouldn’t you be able to afford a little more for hosting? I think Textdrive is leading the charge here. There have been growing pains, but honestly TextDrive is the only host with the guts to stop playing the numbers game. I love Dreamhost, but I don’t think they have a vision for improving Rails hosting into the future. The vapor-y nature of RailsBase is, I think, a testament to the volatility and challenge of the Rails hosting environment. I’ll be waiting with anticipation.

and building my own massive subscription-based app in the meantime