When we launched Just for Bands, my partner Erick and I decided to go with Heroku’s cloud hosting service to host our LiveShow application.  The reasons for this had to do with simplicity in managing the “server” and cost.  Heroku is fairly cheap, and the level of service they provide through their add-ons only increases that value.  If you have a Ruby on Rails application to launch and you don’t want to think about servers, Heroku is definitely worth looking at.

Heroku Worker Dynos

When we launched LiveShow, we utilized what Heroku calls a “Worker Dyno” to handle background tasks, specifically sending emails.  Using a Heroku worker dyno allows you to offload work to a background task so that it doesn’t hold up the actual web server portion of your app.  The downside to worker dynos is they cost money, $0.05/hour to be exact.  And when you run one all day, everyday for a month, that can add up.  In the case of LiveShow, to the tune of over $50 a month. And for a company that isn’t making any real money at the moment, that’s a lot of money going out with next to none coming in.

Enter HireFire

When doing some research for another project, I stumbled on the HireFire gem.  This gem is a must have for anyone who is using Heroku and the worker dynos.  The use of this gem saved us close to $35 in July alone.

What does it do? It’s simple, you set up this gem, and you deploy the changes to Heroku. Once the changes are live on Heroku, you can turn off your worker dyno because this gem will activate one when you generate a background task. You read correctly, it will “hire” a Heroku worker dyno when it notices a new background task has been created.  Once the background task has completed successfully, the HireFire gem will them kill (read “fire”) the worker dyno.  So the worker dynos are only alive when they’re needed.

You can imagine how something like this would reduce the cost of someone (like Just for Bands) that relies on these workers to push out emails and perform other tasks.

The Downside

If you used scheduled background tasks (DelayedJob’s run_at option), this won’t help.  Because HireFire will see the pending job, it will actually keep the worker alive until that job has been ran successfully.

Also, currently, the gem requires you to store your Heroku account credentials in server environment variables on Heroku. There is work to move to using the Heroku API key that each user is given, but it hasn’t been fully implemented yet.  It needs the credentials in order to hire/fire the worker dynos, since it uses Heroku’s APIs for doing the work.

Conclusion

Seriously, if you’re running a Heroku app, and you are using the DelayedJobs or any of the background task runners that HireFire supports, you should highly consider using this gem.  It will drastically reduce your costs, and thus keep your pocket book in check.