Firebase vs Github vs Netlify vs Render vs Cloudflare

One of the early mistakes that we made as a startup was to use one system on one server for both web app and website.

We thought that this would be sustainable, especially since we relied on mostly on interns and volunteers. Everyone would learn one framework and work on one repository and one branch.

The mistake exposed itself when our server actually got website views and web app users. This overloaded our server causing it to either crash or incur charges when it auto-scaled to accomodate the traffic.

The problem is that we had a lot of content waiting to be written for Superphysics and Pantrynomics which were the theory behind the apps. The website would use resources that were supposed to be for the web app users. In addition, our chosen framework was built for web apps and not for CMS or websites.

Solution: Static Site Hosting

I first heard of static site hosting when Github came out with Github Pages. Back then, static site generators were limited and all you had was HTML and Javascript. From 2015, Netlify popularized the concept of Jamstack, which added API – Javascript + API + Markup. This is commonly seen in chat widgets, comment forms, and ’like’ buttons on a webpage.

Back in 2015, we had very little content, so we put it on wordpress.com as drafts. Over the years, we refined the content and gradually put it as styled pages in our web app which acted like an internal mini-CMS.

The need to keep costs low, while improving SEO and managing content, led us to separate the content to static site generators. We forked our mini-CMS as a blogging feature in Pantry (Static site hosting was so good we put blogging on it too).

We chose Hugo as the easiest and fastest static site generator. We then deployed our Hugo sites on different hosts that didn’t require credit cards to see the performance and maintainability:

Host	Pros	Cons
Github Pages	easy to deploy	content must be public
Cloudflare Pages	easy to deploy, integrates with Cloudflare	content must be public
Firebase	easiest to deploy, content isn’t public, creates Google Analytics	needs to install Firebase console
Netlify	Nice UI	content must be public
Render	Nice UI	lets you set up paid services and incur charges, content must be public

Firebase is the easiest to deploy – just hugo && firebase deploy. However, this might be a problem if your internet connection is slow.

Github Pages is great even with slow internet connection – just take the public files and push.

Cloudflare Pages deploys automatically and makes it easy to configure DNS. The site loads a bit faster thanks to Cloudflare’s CDN

Netlify automates the deploy just like Cloudflare Pages, which is great for adding content. But it has less features than Cloudflare.

Render is easier to deploy than Netlify with Hugo themes, but be careful about creating services as they let the meter run even after the trial period! I actually made this mistake when I thought that a certain Javascript framework was categorized as a static site generator (it wasn’t) and so I let it run, thinking it would be free. (Thanks to John of Render for waiving the fee.)

Cloudflare is Great

We decided to use Cloudflare because it’s fast and is easy to deploy. Unlike the others, it does not have bandwidth limits. Instead, it limits the deploys to 500 per month.

For people without coding skills, there are services like forestry.io that allow users to add and edit content just like any CMS.

Update July 2022

• Cloudflare doesn’t seem to work for all domains, so we had to use Netlify in some cases
• Cloudflare enabled IndexNow back in 2021 so it makes sense to push there
• We didn’t use Gitlab Pages because sometimes some internet service providers didn’t allow pushing to Gitlab