What are Heroku Dynos?

In recent weeks' posts, I have been making changes to my personal project EffectiveDonate, including making my React components responsive, optimizing the site for mobile, and improving the UX. All of these changes have been getting me closer to considering EffectiveDonate "production ready".

However one barrier that has stood in the way of production had to do with my settings on Heroku. Heroku is the cloud application platform that I have been using to deploy my web development projects, including EffectiveDonate. The particular problem that I faced had to do with a concept called "dynos" in Heroku, which are the building blocks powering any Heroku app. In this post, I will explain what dynos are, the problem that affected my website, and how I fixed it.

Heroku Dynos

To understand dynos, we must first learn about the concept of containerization in app development. Containerization is what abstracts away the need for app developers to manage hardware or virtual machines. Instead, we just deploy the app to a cloud platform like Heroku, which package the app into containers, which are environments that provide compute, memory, an OS, and a file system.

Heroku uses the container model to handle its apps, and the containers are called "dynos". Dynos are isolated Linux containers that are designed to execute code based on user commands. Heroku apps can dynamically scale to any number of dynos based on resource demands.

Dynos allow app developers to focus on building new projects without needing to worry about managing infrastructure. Cool!

Dyno Types

Heroku offers many different types of dynos, each with their own features, functionality and pricing:

• Free dynos: ideal for experimenting. These dynos sleep after 30 minutes of inactivity to preserve remaining free dyno hours.
• Hobby dynos: good for small scale personal projects. These dynos don't sleep.
• Standard dynos: provide enhanced visibility, performance and scalability for professional apps.
• Performance dynos: provide superior performance when it's most critical.

Dynos in My Project

When I deployed EffectiveDonate to Heroku, I didn't customize any of the performance settings, so it defaulted to using free dynos. I began to notice that whenever I accessed the site for the first time of the day, it would take a long time to load and then I'd get an error message like this:

But when I refreshed the page, the login screen would appear correctly. Although everything ran smoothly after I refreshed the page, having the user land on an error page was obviously not a good UX and gave a poor first impression of the site.

After doing some digging, I learned that this was actually expected behavior when using free dynos, since they sleep after 30 minutes of inactivity. Now that EffectiveDonate was getting close to production status, I decided it was time to upgrade to hobby dynos.

Luckily, hobby dynos cost only $7/month, and are prorated to the time that the dyno is actually in use. So running a dyno for 15/30 days of a month would cost only $3.50 for that month.

In my Heroku Dashboard, I selected my project, navigated to the "Resources" section, and selected "Change Dyno Type". I selected "Hobby", and the change immediately reflected in my project's dashboard.

Now anytime I enter the EffectiveDonate site, the hobby dynos are awake and I am correctly routed to the login page, without a delay or that nasty error page.

Another cool bonus about upgrading to hobby dynos is that a "Metrics" section gets added to your app's dashboard, giving you stats on events, memory usage, response time, throughput, and dyno load.

Conclusion

Dynos had been a concept that kept popping up during my builds and app management, but I had never really dug into them. Researching them has been a good exercise in learning more about cloud concepts such as containerization. And now EffectiveDonate no longer has the poor UX of landing on an error message, so users now correctly reach the login page.

Thanks for reading!