Hosting a static site

Reevaluating’s hosting, making sure it supports HTTP/2 (and a developer-friendly publishing experience).

The website

As enjoyable and useful as Jekyll, Middleman, and Hugo are, this site is not built with any of them. As a front-end developer, I’m extremely comfortable developing it with a custom, JavaScript-based build process.

After using a few static site generators in the past and looking at the landscape, I knew putting together a custom build process would allow for long-term evolution between my choices of template language, site structure, and other build tooling. I could change any of these at any time without running into a wall within an all-in-one static site generator’s ecosystem.

Since this approach has proven effective and maintainable, I was confident in retaining it while reevaluating all other aspects of the site’s hosting and deployment processes.

Previous hosting solution

VPS with Express and Nginx

The server layer consisted of a custom Express server working as a programmable routing engine, coupled with a public-facing Nginx reverse proxy. The use for Express rather than Nginx alone was to trim trailing slashes and file extensions Nginx didn’t seem capable of handling, and to route intelligently between directory index files and other HTML files.


A layer on top of the server itself, CloudFlare provided a CDN with extensive mechanisms to ensure site performance and availability.

Examining the options

The previous solution was fast and reliable, but it had some manual processes. Deployment meant SSHing into the server and running a task to fetch and build from the master branch. Additionally, the server required periodic check-ins to install security patches. I started to think: if another platform can provide a solution more effectively than me, it makes sense to leverage that expertise.

In short, I was looking for a solution to provide straightforward automated deployments, support for new standards like IPv6 and HTTP/2, and end-to-end TLS.

A few options jumped to mind: GitHub Pages, GitLab Pages, or one of several new hosts specifically targeting static sites.

GitHub Pages

GitHub Pages was ruled out right away, due to a need for committing build artifacts into a repository. It would be cleaner to run a build locally and deliver those files via a different mechanism than a Git repository. Alternatively, integrated support for continuous integration runners to build on push would be helpful.

GitLab Pages

GitLab Pages looked promising. In fact, I went through the process of configuring and running it without much trouble. Unfortunately, the server does not strip trailing file extensions and slashes. After realizing this, I kept looking around.

Netlify — what I chose

Netflify focuses on static site hosting as a service, with an emphasis on developer-friendly features. Their platform provides continuous integration through a remote Git repository, a nice default routing configuration, a CDN, HTTP/2 support, and automatically configured TLS through Let’s Encrypt. After authorizing Netlify to read from a repository, builds were running with essentially no configuration, and much faster than with GitLab.

Although there are more providers out there, I’m happy to have found a solution for now that gives this site reasonable performance and security with a little less manual intervention required.