Get 10% OFF hosting service at AlexHost with this voucher code: L59CD15KZ9Y6

Saving costs on Heroku for Ruby on Rails apps

These are some tips to save your costs when running Ruby on Rails apps on Heroku.com. These tips were mainly for developers. You may send those to them though you can do some of the tips by yourself. So, let’s start with the best way for saving costs on Heroku for your Ruby on Rails apps.

Verify your Heroku account with a credit card to get 1000 free dyno hours per month

If you don’t’ verify your account, you only got 650 dyno hours. Assuming your app is not yet going to live, it’s better to use those 1000 free dyno hours. With 1000 hours of wall-clock time, even if your app did not sleep, you won’t run out of hours since there are only 730 hours per month, more or less.

Ensure, that all unused test/staging apps were put in sleep.

Because that free 1000 dyno hour is for an account, not for each app you had in your account. You can do this through the Heroku dashboard and just switch off the web dyno for unused apps there.

Reduce the number of your dyno.

For a web app that had less than 200 unique visitors per day, based on my own experience, it is enough to choose the “Hobby” plan with 1 dyno and 512MB RAM. It costs you $7 per month.

Ask your developers to find out the bottleneck on your app.

This is important. You can use New Relic add on ( available for the free plan, as long as you had verified your account ). Once you and your tech teams found out the bottleneck, ask them to optimize it. For heavier processing, it’s better to move it on a background job and utilize Heroku Scheduler add on. There is no additional cost for utilizing Heroku Scheduler add ons, and it can run every 10 minutes.

Again, ask your developers to use the available resource as much as possible.

You can advise them to use Rails server which supports multi-threads like Puma or Unicorn, instead of Webrick and Thin — for your production app. Puma can improve the ability of your apps to serve more concurrent users though in many cases, Puma will slowly eat your memory (RAM) over time. One of the workarounds is installing the puma-worker-killer gem to kill and restart one of Puma workers when the memory is almost exhausted.

Reduce the number of paid add ons.

Ask your tech team to think more whether it’s really needed to use those paid add ons. Ask them to think for alternatives or build their own solution instead of relying too much on paid add ons. Based on my experience, this can save your costs considerably.

For staging app or test app, always aim for the free dyno.

If possible, never had any more costs on those staging apps or test apps except those apps need important functions where paid add ons is mandatory. An example case is if your Rails app depends on “thinking-sphinx” gem for the searching function. On Heroku, you need “flying-sphinx” add ons to make it works.

Maximize your team ability.

If your team had the capability to set up, maintain, scale, and optimize the infrastructure, then it may make sense to move your entire project out of Heroku. As an alternative, DigitalOcean droplet cost you $5 per month and you get one droplet ( similar to a VPS ). If you had a guy or team with sufficient capability handling it, why not move it there? Another alternative is moving to AWS EC2, but here you pay as you go. You may ask your team to help you calculate each cost for your project, including the risk and consequences among them: Heroku, AWS, or Digital Ocean.

P.S. I am not affiliated or work for any of them. I just had some experiences to work on all of those services.


Categories: Ruby on Rails  

Tags: heroku   ruby on rails