.

content/posts/nixos-remote-auto-static-site-deploy.md

@@ -0,0 +1,115 @@
+---
+title: over-engineered (?) nixos blog deployment setup
+date: 2025-08-11
+tags:
+  - nixos
+draft: false
+---
+
+As is traditional with people hosting their own blog I'm going to do a post detailing EXACTLY how I'm hosting my blog.
+Down to the last dirty detail.
+I have nothing better to talk about.
+Here is a diagram I edited to illustrate (credit to xkcd I think?).
+
+![self-hosting](/image/self-hosting.png)
+
+I host my site on a hetzner vps running nixos.
+I also have a git repo where all the static files for my blog live.
+I had previously been manually rsyncing the website up to my vps from my laptop.
+Qute an easy, efficient solution; it worked well.
+But not very nixos; far too simple, not sufficiently over-engineered.
+So in true nixos fashion I decided I'd spend a couple of hours sorting the problem so I'd maybe save a minute once a year when I write a blog post.
+
+### Remote Rebuilds
+
+First, I'll show the fancy way to rebuild your remote nixos systems via ssh.
+In my case, this means I can rebuild my hetzner box from my laptop.
+You can read the wiki about it [here](https://wiki.nixos.org/wiki/Nixos-rebuild#Deploying_on_other_machines).
+
+This sets up ssh with key-based authentication and lets our local user in.
+This config belongs on the remote machine.
+
+```nix
+users.users.blog-king.openssh.authorizedKeys.keys = [ 
+  # ssh public key on computer you're deploying from
+  "ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIPzFa1hmmmmmPL5HvJZhXVEaWiZIMi34oR6AOcaaaaaaa"
+];
+
+nix.settings.trusted-users = [ "blog-king" ];
+
+# ssh daemon
+services.openssh = {
+  enable = true;
+  openFirewall = true;
+  settings = {
+    PasswordAuthentication = false;
+    PermitRootLogin = "no";
+  };
+};
+
+```
+
+Once you have this going on your remote machine (in my case the hetzner vps) you should be able to rebuild the remote machine with `nixos-rebuild --target-host blog-king@remote-ip-here --ask-sudo-password switch`.
+The `--ask-sudo-password` is not required if you ssh in as root though that would be a touch gauche.
+
+### Caddy
+
+You can do this with whatever your preferred webserver is.
+I am a caddy stan.
+This opens the necessary ports in the firewall and sets up caddy in file server mode pointing at `/etc/blog`.
+
+```nix
+networking.firewall.allowedTCPPorts = [
+  80
+  443
+];
+
+services.caddy = {
+  enable = true;
+  extraConfig = ''
+    blog.example.org {
+      root * /etc/blog
+      file_server
+    }
+  '';
+};
+```
+
+### Getting the files from git
+
+We have a web server pointing at `/etc/blog`.
+The last piece of the puzzle is to get the static files from our git repo and spit them out in that directory.
+
+I'm using the `fetchFromGitea` helper here which works for gitea and forgejo instances.
+The `fetchFromGitHub` helper would look very similar.
+
+You can get the `rev` and `sha256` of the commit using `nix-prefetch-git`.
+
+Also note the little `/public` at the end of the `source` string.
+That's the directory of the git repo that the website source lives.
+
+```nix
+environment.etc."blog" = {
+  enable = true;
+  target = "blog";
+  source = "${
+    pkgs.fetchFromGitea {
+      domain = "git.example.org";
+      owner = "james";
+      repo = "blog";
+      rev = "32d81f01388c88a259eed2ba52f4545dbcb1eb07";
+      sha256 = "173g99dj8y4sw1v7f1s5f7zgcrrlr6dly9n6ysr2i4jg095lkxw8";
+    }
+  }/public";
+  user = "caddy";
+  group = "caddy";
+};
+```
+
+So now with all that setup the blog post work flow is:
+
+- Commit rebuilt website to repo
+- Update the `rev` and `sha256` to the new commit (this is annoying and I'm trying to work out a good way to automate it)
+- Rebuild vps from laptop
+
+Not necessarily faster than the old rsync method but it's pretty damn declarative, that's for sure.