Goodbye, Github Pages

2021-01-23  •  (Updated 2022-05-21)  •  This blog is no longer sponsored by Microsoft!

This post is part of a series:
Next: Self-Hosted Email With maddy: A Naive First Attempt

Slowly but surely I'm working on moving my digital life back to being self-hosted, and this blog was an easy low-hanging fruit to tackle. Previously the blog was hosted on Github Pages, which was easy enough but also in many ways restricting. By self-hosting I'm able to have a lot more control over the generation, delivery, and functionality of the blog.

For reference you can find the source code for the blog at Yes, it will one day be hosted elsewhere as well.


Nix is something I'm slowly picking up, but the more I use it the more it grows on me. Rather than littering my system with ruby versions and packages I'll never otherwise use, nix allows me to create a sandboxed build pipeline for the blog with perfectly reproducible results.

The first step in this process is to take the blog's existing Gemfile.lock and turn it into a gemset.nix file, which is essentially a translation of the Gemfile.lock into a file nix can understand. There's a tool called bundix which does this, and it can be used from a nix shell without having to actually install anything:

 nix-shell -p bundix --run 'bundix'

The second step of using nix is to set up a nix expression in the file default.nix. This will actually build the static files. As a bonus I made my expression to also allow for serving the site locally with dynamic updating everytime I change a source file. My default.nix looks like this:

    # pkgs refers to all "builtin" nix pkgs and utilities. By importing from a
    # URL I'm able to always pin this default.nix to a specific version of those
    # packages.
    pkgs ? import (fetchTarball "") {},
    system ? builtins.currentSystem,

        # bundlerEnv looks for a Gemfile, Gemfile.lock, and gemset.nix inside
        # gemdir, and derives a package containing ruby and all desired gems.
        ruby_env = pkgs.bundlerEnv {
            name = "ruby_env";
            ruby = pkgs.ruby;
            gemdir = ./.;
            # build will derive a package which contains the generated static
            # files of the blog. It uses the file (provided below) to
            # do this.
            build = derivation {
                name = "mediocre-blog";

                # The file (source provided below) is executed in order
                # to actually build the site.
                builder = "${pkgs.bash}/bin/bash";
                args = [ ./ ];

                # ruby_env is provided as an input to so that it can
                # use jekyll, and the src directory is provided so it can access
                # the blog's source files. system is required by the derivation
                # function, and stdenv provides standard utilities to
                inherit ruby_env system;
                src = ./src;
                stdenv = pkgs.stdenv;

            # serve will derive an environment specifically tailored for being
            # run in a nix-shell. The resulting shell will have ruby_env
            # provided for it, and will automatically run the `jekyll serve`
            # command to serve the blog locally.
            serve = pkgs.stdenv.mkDerivation {
                name = "mediocre-blog-shell";

                # glibcLocales is required so to fill in LC_ALL and other locale
                # related environment vars. Without those jekyll's scss compiler
                # fails.
                # TODO probably get rid of the scss compiler.
                buildInputs = [ ruby_env pkgs.glibcLocales ];

                shellHook = ''
                    exec ${ruby_env}/bin/jekyll serve -s ./src -d ./_site -w -I -D

(Nix is a bit tricky to learn, but I highly recommend chapters 14 and 15 of the nix manual for an overview of the language itself, if nothing else.)

The used by the nix expression to actually generate the static files looks like this:

# stdenv was given a dependency to, and so can use it to
# source in utilities like mkdir, which it needs.
source $stdenv/setup
set -e

# Set up the output directory. nix provides the $out variable which will be the
# root of the derived package's filesystem, but for simplicity later we want to
# output the site within /var/www.
mkdir -p "$d"

# Perform the jekyll build command. Like stdenv the ruby_env was given as a
# dependency to, so it has to explicitly use it to have access to
# jekyll. src is another explicit dependency which was given to, and
# contains all the actual source files within the src directory of the repo.
$ruby_env/bin/jekyll build -s "$src" -d "$d"

With these pieces in place I can easily regenerate the site like so:

nix-build -A build

Once run the static files will exist within a symlink called result in the project's root. Within the symlink will be a var/www/ tree of directories, and within that will be the generated static files, all without ever having to have installed ruby.

The expression also allows me to serve the blog while I'm working on it. Doing so looks like this:

nix-shell -A serve

When run I get a normal jekyll process running in my src directory, serving the site in real-time on port 4000, once again all without ever installing ruby.

As a final touch I introduced a simple Makefile to my repo to wrap these commands, because even these were too much for me to remember:

	nix-build -A build

install: result
	nix-env -i "$$(readlink result)"

	rm result
	rm -rf _site

	nix-shell -A serve

	nix-shell -p bundler --run 'bundler update; bundler lock; bundix; rm -rf .bundle vendor'

We'll look at that install target in the next section.


So now I have the means to build my site quickly, reliably, and without cluttering up the rest of my system. Time to actually serve the files.

My home server has a docker network which houses most of my services that I run, including nginx. nginx's primary job is to listen on ports 80 and 443, accept HTTP requests, and direct those requests to their appropriate service based on their Host header. nginx is also great at serving static content from disk, so I'll take advantage of that for the blog.

The one hitch is that nginx is currently running within a docker container, as are all my other services. Ideally I would:

Unfortunately extracting nginx from docker is dependent on doing so for all other services as well, or at least on running all services on the host network, which I'm not prepared to do yet. So for now I've done something janky.

If you look at the Makefile above you'll notice the install target. What that target does is to install the static blog files to my nix profile, which exists at $HOME/.nix-profile. nix allows any package to be installed to a profile in this way. All packages within a profile are independent and can be added, updated, and removed atomically. By installing the built blog package to my profile I make it available at $HOME/.nix-profile/var/www/

So to serve those files via nginx all I need to do is add a read-only volume to the container...

-v $HOME/.nix-profile/var/www/ \

...add a new virtual host to my nginx config...

server {
    listen       80;
    root         /var/www/;

...and finally direct the blog A record for to my home server's IP. Cloudflare will handle TLS on port 443 for me in this case, as well as hide my home IP, which is prudent.


So now it's time to publish this new post to the blog, what are the actual steps? It's as easy as:

make clean install

This will remove any existing result, regenerate the site (with the new post) under a new symlink, and install/update that newer package to my nix profile, overwriting the previous package which was there.

EDIT: apparently this isn't quite true. Because $HOME/.nix-profile is a symlink docker doesn't handle the case of that symlink being updated correctly, so I also have to do docker restart nginx for changes to be reflected in nginx.

And that's it! Nix is a cool tool that I'm still getting the hang of, but hopefully this post might be useful to anyone else thinking of self-hosting their site.

If you liked this post, consider checking out other posts in the series:
Next: Self-Hosted Email With maddy: A Naive First Attempt