This blog has been built with Nix for some time, but the deployment of the blog has been a hand-written shell script that just rscny’d the files across to a VPS. How quaint.
I was bored and looking for a reason to try it out, so now all the deployment happens with Nixops, which is really quite nice.
Here’s the file that defines the server that it’s hosted on (
This is pretty straightforward.
www.michaelpj.comis the actual website
/blogpoints to the output of the blog derivation, which is the static site (note that this is actually a directory in the Nix store!)
/.well-knownpoints to the
.well-knownfolder (again, this will be copied into the Nix store)
The nice thing about this is that I can then deploy it to multiple backends transparently. I have a simple virtualbox backend set up:
This will create a single VM running the blog. This doesn’t work quite as well
as I’d like, because the VM obviously doesn’t have the right hostname, so
redirects don’t work well. However, making the
www.michaelpj.com virtual host
the default makes this work in practice.
The other backend is on Vultr.
This is pretty bare-bones, since there isn’t a proper Vultr backend yet, so it’s using the “none” backend to talk to an existing NixOS machine. That is, NixOps isn’t going to be creating and destroying the VM, I did that manually and NixOps just manages its configuration.
The sum total of this is quite nice. I have two deployments set up:
nixops create server.nix virtual.nix -d testing nixops create server.nix vultr.nix -d production
Now I can test out any changes to the site with
nixops deploy -d testing, and
do an actual deploy with
nixops deploy -d production. And of course I get
atomic rollbacks for free with
Complete overkill for a simple static blog? Sure. I’m not really making use of the ability to manage the creation of machines (except for the local VMs), and I’m not deploying multiple machines. But it’s still pretty nice.