The Experiment’s Table of Contents
Part 1: An Experiment in the Making
Part 2: Getting Started with DigitalOcean
Part 3: Handling Redirects with DigitalOcean
Part 4: The Experiment Continues
Part 5: Deploying to Heroku
I’ve gotten a few requests to hurry up with this experiment. It’s been a while…I know. But finally…I’ve done it: I’ve deployed my personal portfolio to Heroku successfully!
If you don’t already know, Heroku is an ephemeral PaaS. Again, I’m a front-end guy so that statement is foreign language to me. Ultimately, it means that while it allows you to deploy a website onto the platform, it does not give you full hosting like say DigitalOcean or MediaTemple. You have to figure out database and image management yourself. They do have a ton of add-ons (which we will get into later) that can aid in this process. However, if you are not careful the cost for these addons can pile up quickly. Heroku offers a free tier so that you can test. You get 1,000 dyno hours per month. Be careful because that is a 1,000 dyno hours a month for ALL free applications under your account…not 1,000 per application.
Considering this is a portfolio site and I’m not famous (…yet) traffic to my portfolio is abysmal. Keeping my portfolio on Heroku’s free tier doesn’t seem like a huge issue to me. I have the ability to add a custom domain to the site. The only challenge is that free dynos do not stay woke. Meaning after 30 minutes of inactivity, it goes to sleep and has to be re-awaken. That re-awaken period can take a second for visitors. There are methods to make sure your dyno remains on but…that’s for another post. Also, going to a paid tier allows me to add a SSL certificate to the domain.
Going back to my list, my next steps were as follows: — Find a cloud database solution — Install Perch’s Cloudinary Template filter onto the site — Connect Github and Heroku — Deploy site to Heroku
First things first, I had to create a Heroku app. There are a few ways to make that happen. You can do this the Matrix Way (aka command line) or the WYSIWYG Way (aka Heroku’s dashboard). I wanted to feel like a super backend developer so I opted the Matrix Way. I followed the instructions for the PHP setup since the site is ran on PHP but built using NodeJS.
Note: When running a site on Heroku with PHP, you have to have a composer.json file. My file is completely empty considering I don’t have any PHP dependencies on the site. The file still is needed as it indicates that you have PHP site that needs to be built. This is Heroku’s attempt at a zero configuration set up.
By the end of the instructions, you’ve got your site up and running…but I still needed to add NodeJS to my build since I don’t ship any destination files via Git. I won’t lie: THIS PART KICKED MY BUTT. After a lot of testing and experimenting, I finally wrapped my head around adding a new Buildpack and was able to get my site built and deployed properly to Heroku.
Next, it was time to get a database together. Remember those addons I spoke of? Well, Heroku has a bunch of them to help you out in this department. I ended up using ClearDB for the database. I opted to leave my WordPress instance out of the Heroku part of the experiment. We’ll talk more to that in the final post.
Next, was the images that get uploaded to Perch. All of my portfolio screenshots are uploaded via the backend of Perch. So what I needed as a way to easily host these images. Heroku does have addons like Cloudcube and HDrive but I wanted something a little more easy and cheaper. I landed on Cloudinary as my cloud asset host. You can see more about my decision in my previous post. I did chose to scrap Perch’s Cloudinary Template filter. I found one but decided against using it and just simply used the Autoupload method of getting images into Cloudinary.
The last part to figure out was how to get environment variables to point to the database. On DigitalOcean, I could simply upload a config.local.php file to my site that was not kept inside of Git. Heroku doesn't have an FTP option so I was left with their config variables in the app settings. This feature was pretty nifty since now all my private data is left outside of Git and still accessible to the app.
After figuring all the above out, I must say…Heroku is not that bad. Figuring all this stuff out is a pain in the butt. However, once you get it down, it makes for a great and cheap alternative to traditional hosting for sites that don’t receive a lot of traffic.
And that’s it folks. I’m going to sit on this site for a little bit. I would love fabricate some traffic to the site to see how it handles it. That way I can experiment with scaling the site up. Let me know in the comments if you guys would like to see a video version of this experiment that walks thru all the steps and my thought process.
Disclaimer: Some of the links provided in this article are referral links where I get bonus time on the services if you click and sign up.
Top comments (0)