A tiny case study about migrating to Netlify when disaster strikes at GitHub, featuring Cloudflare
Tags: hosting, deployment, netlify, showdev
Published: 2018-11-02 15:37:46

---
title: A tiny case study about migrating to Netlify when disaster strikes at GitHub, featuring Cloudflare
published: true
tags: hosting, deployment, netlify, showdev
canonical_url: https://codewithhugo.com/a-tiny-case-study-about-migrating-to-netlify-when-disaster-strikes-at-github-featuring-cloudflare/
---

> Last Monday (22 October 2018) GitHub was going 💥, and scheduled content on Code with Hugo wasn’t going live.

For context, the blog’s setup is documented in [“Switching the lights on: Hugo vs Hugo config files”](https://codewithhugo.com/switching-the-lights-on-hugo-vs-hugo-config-files/).

**tl;dr** _(as is relevant to this post)_

- Cloudflare DNS + CDN + proxying + HTTPS
- GitHub Pages
- [Hugo](https://gohugo.io) as a static site generator
- CircleCI to deploy the site daily + on push (🤷‍♀️wasn’t in the post but that’s how I do it)

Contents of this post:

<!--
- [On hosting with a business which isn’t specialised in static hosting 🤔](#on-hosting-with-a-business-which-isnt-specialised-in-static-hosting-)
- [Speedy migration to Netlify ⏩](#speedy-migration-to-netlify-)
- [Why use Cloudflare then?](#why-use-cloudflare-then)
- [The path forward](#the-path-forward)
-->
- On hosting with a business which isn’t specialised in static hosting 🤔
- Speedy migration to Netlify ⏩
- Why use Cloudflare then?
- The path forward

## On hosting with a business which isn’t specialised in static hosting 🤔

Back to the story: [codewithhugo.com](https://codewithhugo.com) was not building or publishing on GitHub Page… which means my post [“Simple but not too simple: how `micro` improves your Node applications”](https://dev.to/hugo__df/simple-but-not-too-simple-how-using-zeits-micro-improves-your-node-applications-1kah), scheduled for publication at 7AM UTC (I’ll write up how I do this one day [subscribe to get it in your inbox](https://buttondown.email/hugo))… Didn’t go live.

As it turns out, the GitHub team itself struggled to get a post out during this period: [“We use GitHub Pages internally and all builds had been paused several hours earlier, so publishing this took additional effort.”](https://blog.github.com/2018-10-30-oct21-post-incident-analysis/#2018-october-22-0746-utc)

What’s worse, GitHub’s web-hooks and other core APIs were either unavailable or really flakey/disrupted. Which means that migrating to Netlify wasn’t as simple as usual: “deploy from git” wouldn’t work due to disruptions on GitHub’s end.

## Speedy migration to Netlify ⏩

A great Netlify feature is “manual deploys”, where you just upload a zip and it deploys it as a static site. Thankfully the latest version on my GitHub Pages repository had the post I wanted (it just couldn’t deploy it).

Getting the site up on Netlify was simple enough:

- download the repository’s zip archive from GitHub (thankfully this wasn’t on fire 🚒 like the rest of GitHub)
- upload it to Netlify using the dashboard

At this point the site is live on a `*.netlify.com` domain.

Getting the codewithhugo.com domain pointing to Netlify:

- Update the `A` records on Cloudflare’s DNS to Netlify’s load balancer `104.198.14.52`

What surprised me is how fast the update happened. A DNS update should take time to propagate. Except this wasn’t strictly a DNS update since I’m using Cloudflare’s proxied DNS. That means if you `dig codewithhugo.com` you get the following answer section:

```
;; ANSWER SECTION:
codewithhugo.com. 299 IN A 104.27.140.8
codewithhugo.com. 299 IN A 104.27.141.8
```

Suprise! 🎉 those records don’t point to Netlify (or GitHub Pages), they point to Cloudflare (see [https://www.abuseipdb.com/whois/104.27.140.8](https://www.abuseipdb.com/whois/104.27.140.8) and [https://www.abuseipdb.com/whois/104.27.141.8](https://www.abuseipdb.com/whois/104.27.141.8)). Cloudflare then proxies to Netlify’s load balancer. Super 👏 neat 👏 .

## Why use Cloudflare then?

> Well since [@github](https://twitter.com/github?ref_src=twsrc%5Etfw) Pages stopped building with all the issues, thanks to [@Netlify](https://twitter.com/Netlify?ref_src=twsrc%5Etfw)’s `zip upload` functionality and [@Cloudflare](https://twitter.com/Cloudflare?ref_src=twsrc%5Etfw)’s proxied DNS service I’ve been able to get the blog post I scheduled for today live.
> 
> 👏👍
> 
> — Hugo Di Francesco (@hugo\_\_df) [22 October 2018](https://twitter.com/hugo__df/status/1054350487372349440?ref_src=twsrc%5Etfw)

When I first published [“Switching the lights on: Hugo vs Hugo config files”](https://codewithhugo.com/switching-the-lights-on-hugo-vs-hugo-config-files/), one of the reactions I received was: [“You don’t seem to explain any reason for using CloudFlare on top of GitHub pages. Care to elaborate?”](https://dev.to/lietux/comment/4od9).

To which I replied ([see the comment here](https://dev.to/hugo__df/comment/5115)):

- HTTPS (pretty sure it didn’t use to be a thing with custom domains on GitHub pages)
- CDN
- DNS

Which even I didn’t find that compelling, now I guess I do have a compelling reason to use Cloudflare: you’re able to change hosting provider within minutes if you leverage Cloudflare’s proxied DNS + CDN service.

I think due to Cloudflare’s proxying and Netlify’s manual deploy saving my bacon in this instance (Monday is newsletter day and I wanted to get the `micro` post in there), it’s brought value enough to justify my stack choice.

## The path forward

![✅ Don't switch back to GitHub Pages #codewithhugo](https://d2mxuefqeaa7sj.cloudfront.net/s_5691CB595260242ACD57C6976EE88A660D47EA1777643C78B1E18DEE1EB217B5_1540484787181_image.png)

Since I host my static sites on Netlify now ([see “Deployment options: Netlify + Dokku on DigitalOcean vs now.sh, GitHub Pages, Heroku and AWS”](http://Deployment%20options:%20Netlify%20+%20Dokku%20on%20DigitalOcean%20vs%20now.sh,%20GitHub%20Pages,%20Heroku%20and%20AWS)), I’ve decided that maybe sticking [codewithhugo.com](https://codewithhugo.com) on there permanently is a good idea. Sorry GitHub Pages.

> If you want to migrate a HTML [@github](https://twitter.com/github?ref_src=twsrc%5Etfw) Pages site to [@Netlify](https://twitter.com/Netlify?ref_src=twsrc%5Etfw) here’s an example config (tl;dr: use Publish Directory “.”) [pic.twitter.com/pDvlMXnCoc](https://t.co/pDvlMXnCoc)
> 
> — Hugo Di Francesco (@hugo\_\_df) [23 October 2018](https://twitter.com/hugo__df/status/1054679262584823808?ref_src=twsrc%5Etfw)

Here’s an example config for deploying a site hosted on GitHub (that would work as a GitHub Pages site) to Netlify:

![Example config to deploy a GitHub Pages site from GitHub to Netlify](https://d2mxuefqeaa7sj.cloudfront.net/s_5691CB595260242ACD57C6976EE88A660D47EA1777643C78B1E18DEE1EB217B5_1540486742344_DqL5IruWkAAlwyF.jpg)

Pretty simple, publish the root directory using `Publish Directory: .` and don’t set a build command.

GitHub Pages is awesome, my demos are likely to still live there. Disruptions happen to everyone but as is [clear in their post-mortem](https://blog.github.com/2018-10-30-oct21-post-incident-analysis/), GitHub isn’t a static hosting service 🙂. Netlify’s core business proposition is static site hosting and deployment, that’s why [Code with Hugo](https://codewithhugo.com) is going to live there from now on 👍.

[<svg xmlns="http://www.w3.org/2000/svg" style="height:12px;width:auto;position:relative;vertical-align:middle;top:-1px;fill:white" viewbox="0 0 32 32"><title>unsplash-logo</title>
<path d="M20.8 18.1c0 2.7-2.2 4.8-4.8 4.8s-4.8-2.1-4.8-4.8c0-2.7 2.2-4.8 4.8-4.8 2.7.1 4.8 2.2 4.8 4.8zm11.2-7.4v14.9c0 2.3-1.9 4.3-4.3 4.3h-23.4c-2.4 0-4.3-1.9-4.3-4.3v-15c0-2.3 1.9-4.3 4.3-4.3h3.7l.8-2.3c.4-1.1 1.7-2 2.9-2h8.6c1.2 0 2.5.9 2.9 2l.8 2.4h3.7c2.4 0 4.3 1.9 4.3 4.3zm-8.6 7.5c0-4.1-3.3-7.5-7.5-7.5-4.1 0-7.5 3.4-7.5 7.5s3.3 7.5 7.5 7.5c4.2-.1 7.5-3.4 7.5-7.5z"></path></svg>Anthony Cantin](https://unsplash.com/@arizonanthony?utm_medium=referral&utm_campaign=photographer-credit&utm_content=creditBadge "Download free do whatever you want high-resolution photos from Anthony Cantin")