Heroku to Firebase
Serving Directly from Google Cloud
When Google decided to label all unencrypted websites (HTTP) as Non-Secure, I knew my blog would also be affected since I hadn’t set up encryption. Initially, it didn’t bother me much, as my blog was simple and didn’t require visitor data. However, when I learned that non-secure websites would no longer appear in Google search results, I knew I had to take action, and quickly.
Back in 2013, I wrote about hosting websites on Heroku, and it completely changed my approach to development. I could focus on coding without worrying about hosting – it just worked.
Even with the Free Plan, Heroku met my needs. I served all my static assets from the Incapsula CDN (Content Delivery Network), which eliminated delays caused by waiting for the dyno to wake up. For media, I used Cloudinary, which had its own CDN. I migrated all my previous projects to Heroku, unsubscribed from previous hosting services, and found great satisfaction in the progress.
The End of the Honeymoon Period
To implement an SSL certificate for HTTPS, I had no choice but to sign up for the $7/month Hobby Plan. Considering my basic requirements and the currency exchange rate in my country (MYR), it didn’t seem like a worthwhile investment. After all, I didn’t have plans to attract heavy traffic or monetize my blog. It remained a hobby and experimental web app for me to play around with.
So, I began searching for alternatives that would work with my current development setup. Since I had heavily customized my nanoc setup, there was a risk that I’d have to rebuild everything – something I wanted to avoid.
Firebase to the rescue
Initially, I considered creating a Debian droplet on DigitalOcean, which would cost me $5 per month. I was enticed by the freedom it offered for expanding capabilities. However, upon careful consideration, I decided against it.
I established three criteria to guide my search for a suitable replacement:
1. Mandatory cloud-based service: It had to support Git or terminal deployment.
2. Reasonable plans and pricing: It had to be budget-friendly, even if not entirely free.
3. Seamless integration into my existing setup: I wanted to avoid unnecessary complications.
After a week of searching, Firebase emerged as the only reasonable replacement that met all my criteria for hosting my blog in the cloud.
Take a look at its key capabilities:
Armed with nothing but official documentation and the hosting behavior guide, I embarked on the process of migrating to Firebase. First, I made a copy of the Heroku working folder, modified the Gemfile to remove Heroku-specific gems, and ported over the rack’s config.ru to firebase.json as closely as possible. Then, I ran “firebase serve” to verify if the JSON was functioning properly.
In less than an hour, everything was ready for deployment. The Firebase/Google guides were well-written and comprehensive. Since my blog didn’t have a large number of visitors, I proceeded with the migration and pointed my domain to Firebase.
Note: For websites with high traffic, other considerations may apply.
It took a few hours for my blog to be fully ready as Firebase provisioned the SSL certificate. During that time, an invalid certificate warning served as the centerpiece of my blog.
A few hours later, I successfully migrated all my projects to Firebase. Managing everything under one bucket was easy, and it was a bonus that one bucket could fulfill all my needs.
With Firebase’s built-in CDN and ample storage for all my assets, I deactivated Incapsula CDN and deleted my Cloudinary account. However, bidding farewell to my Heroku account proved to be the toughest part. It was my first love when it came to cloud computing.
Some of this commit took place when I was sitting at the beach, enjoying the day.
Looking back, I realized that I had deployed 546 times since signing up with Heroku. Each deployment held a story and memory that I reminisce about from time to time. But in the end, nostalgia couldn’t keep me from going.