New Year Tidy Up: Hosting Static Sites

It’s that time of year where lots of blog authors are publishing their 2017 year-in-review style posts. I enjoy those and had a loose idea to do one myself. Instead, I got distracted trying to tidy up several years worth of confusion on an old VPS instance.


Recently as part of my day job I’ve been starting to investigate how parts of our infrastructure can be moved away from machines and VMs that we have to manage. The idea is that we’ll be working smarter by focusing on the parts where we 1) add value and 2) are proficient enough to run XYZ service better than someone else (or more cost effectively than someone else!).

Maybe it’s too much New Year’s Day fresh air, but this got me thinking about my own personal infrastructure, although, ‘infrastructure’ is too strong a word to use here. We are talking about a couple of VPS instances and a local server under my desk that I think is still running fine.

The question is, which services am I running that really should be handled elsewhere or reconfigured somehow?

Starting Small with Static Sites

I decided to start with the easiest part of my setup, which is the handful of static sites that I’ve been hosting. These range from an old company holding page, to a list of employers who train their staff with CIMA. These little sites currently live in an unloved and often forgotten part of my VPS. I want to move them. Sure, they don’t take up many resources being made up of some web server config and a few flat files but they’re just extra parts that I don’t want to have to care about running.

If possible, I’d also like to host the sites somewhere with a very low cost, and by that I mean for free.

Azure Free Hosting?

I’d heard that Azure could be a good option. Until recently I’ve had very little interaction with Azure, so I’ve been interested to find out more about their offering compared to AWS and friends. They have a low resource free tier (F1) that you can use to run web apps. A static site seems very low resource indeed, but it wasn’t meant to be. Their free offering does not allow custom domains, and whilst I’ve not overly against foo-bar.azurewebsites.net I’d rather keep it under my own domain.

Another option was to use their block storage, which does all you to use a custom domain. This however is not free. Although it’s cheap, I decided to pass for now.

How about an Amazon S3 Bucket?

Looking at Azure’s block storage also reminded me of Amazon’s trusty offering with S3. I’ve previously run static sites from S3 and they do have a free tier which looked like it might work out. This would have been my solution for these static sites if not for Github.

Github Pages

I eventually settled on Github pages. By default I associate Github pages with a repo’s documentation or brochure website, but there’s no reason you can’t host other sites from a Github repo. Plus, custom domains are supported out of the box. The limits are fairly generous, especially for the tiny amount of bandwidth the sites I’d be moving would see.

The real clincher when comparing against S3 was the deployment method. Being able to create a commit and push to github to deploy a new version is ideal. The sites I’d be moving all have underlying repos anyway, albeit sometimes with only two commits and a quick and cheap script for web scraping and content generation. Having the repo and end result managed from the same place seemed like a no brainer.

A few gotchas for Github page setup, if you’ve not used the feature previously:

  • Github pages are enabled per repo via the Settings tab. You then need to set the source for the Github pages.
  • You can set your Github pages site root as either the root of the repo, or create a /docs folder (not a folder with just any name).
  • If you want to use a /docs folder you have to tell Github via the repo settings.
  • If you want to use a custom domain you’ll need to make a CNAME record from whatever you want to use to [your-github-username].github.io.
  • You’ll also need to create a file called CNAME in the Github pages root of the repo (either / or /docs) where the file content is the custom domain you’re wanting to use.

New Year’s Resolutions

A loose aim for this year is to keep my personal dev tools clearly configured and running in a sensible way. Moving a few static sites was a toy project to get started, but for the harder parts I’m hoping the synergy between moving around infrastructure at work and home will help me learn some new tooling and better service management.

Github pages was easy to use and fits in seamlessly with my existing workflow of using git for almost everything. Bonus points also for not requiring me to sign up to yet another online service. A good result for the start of the year.

Dev Git SysAdmin
Back to posts