Ylan Segal

Manage Your App's Multiple Processes With a Procfile

On simple web applications, it’s common to talk about a “develpment server” which one starts before coding. Any rails developer is familiar with rails s. It boots up your application and it’s ready to view on your favorite browser. As applications start to grow, so do the number of processes that your application depends on. Using memcached? Make sure it’s running. Need background processing? Better start your background worker. Pretty soon, you have half a dozen terminal tabs open and you haven’t begun coding yet. There is a better way.

Deploy to Heroku With (Near) Zero Downtime

Heroku offers a great hosting platform that abstracts away most of the system administration tasks inherent in running an app. I have generally been very happy hosting productions apps in Heroku and have managed to do very well with it’s platform and it’s available add-ons to increase functionality. I really like the way the handle Postgres databases, which makes things like followers, clones and backups a simple 1-off command.

For a long time, though my main gripe has been deployment. Initiating a deployment could not be easier: Just push to your app’s git repository in Heroku. My problem is what happens on restart.

Better Performance on Heroku: Thin vs. Unicorn vs. Puma

UPDATE: These benchmarks where updated in 2013 and 2014.


Heroku’s Cedar stack provides great flexibility in the type of processes you can run, including the ability to choose which application server to deploy.

I have been running thin, since it’s the recommended option and also the safe default, since that is what the app was running in the Bamboo stack, before migrating to Cedar.

However, I have read recently about getting better performance out of the same amount of dynos, and my interest was piqued. Before heading straight for Unicorn, I decided to give Puma, the new kid on the block a try.