I am not sure why people tends to over engineer a simple task, such as hosting a static site. Cloudflare or other static site hosting vendors are much easier with probably lesser energy consumption.

Sweet! I did something similar to this a while ago: https://github.com/LutrisEng/nix-fly-template

Mine was using nginx, but otherwise was pretty similar. I really love “abusing” flake apps like this to make a script that uses data files from its closure to do something stateful (importing Docker images, deploying to Fly.io, I could imagine deploying Helm charts or running a kubectl apply being doable as well).

Thank you for the writeup! As someone struggling to use nix for anything and glibly deciding it’s everyone else’s fault, I have some comments/questions:

• Thank you for not using with! As a beginner with is total evil for me, because I cannot know what is defining top-level values.

• Thank you for making me discover callPackage! This actually is a major source of issues for me. Nix is “just functions” yet somehow everyone seems to have access to weird magic that means they can get dependency injection by changing their function signature. Honestly, after reading this, the documentation, and experiencing loads of confusion from this: is it really worth doing this compared to pkgs.foo everywhere? You can still build a set from the outside when you want, and it means one less piece of “magic”

• you had a lot of comments in your flake.nix, it would be interesting to see one extra thing defined in inputs to be able to more deeply understand how that 3-step flow actually works in practice

• You have caddyfile = builtins.readFile ./Caddyfile; and then… I believe are injecting the text into the command line. What would building up the dockerfile look like if you wanted to add that file into the root?

• similarly, in site.nix, you had src = ./.. Is there an easy way to define globs or the like? For example I have a static site that has a build process, so really I just want to package up built artifacts, and easily exclude certain types of files

• I’m not 100% clear what your final flake.nix looks like here, would it be possible to put it in a gist or something?

Sorry for the big comment wall, in any case this is super useful, as I was just yesterday trying to figure out how to move a Heroku app over and was trying (and failing) to use nix in this process

Wow - completely coincidentally I also moved my website from Cloudflare to Fly.io (served using Caddy) this afternoon. No Nix though :)

Caddyfiles look neat. Could they be the solution to how horrible it is to deploy various self-hosted apps?

I am migrating my website to fly.io and using caddy as webserver, nix is not currently in the architecture but will surely read this! Thanks :)

I followed this, made a couple of adjustments to allow hugo themes to work (feel free to include in the article if you want), and got my first fly.io site up. Thanks for that!

If you want to use a hugo theme, nix flakes don’t support git submodules at present (was reverted), so I needed to find another way for hugo to be able to get access to the theme.

In my hugo config.toml:

theme = "nix-theme"

In my flake.nix, I added this to inputs:

theme.url = "github:panr/hugo-theme-terminal";
theme.flake = false;

then I pull it out in the outputs params:

outputs = { self, flake-parts, theme, ... }:

then in the per-system section, I updated devShells.default and packages.default to pass theme:

devShells.default = import ./shell.nix { inherit pkgs theme; };
packages.default = pkgs.callPackage ./site.nix { inherit theme; };

In site.nix, I removed the installPhase and did this, instead:

{ stdenv, hugo, scour, theme }:

#...

buildPhase = ''
  mkdir -p themes && ln -s ${theme} themes/nix-theme
  scour -i favicon-original.svg -o favicon.svg
  hugo -D -d $out
'';
dontInstall = true;

This adds a symlink for themes/nix-theme folder pointing to the flake theme input.

For shell.nix, here’s the file:

{ pkgs ? import <nixpkgs>, theme }:
pkgs.mkShell {
  buildInputs = [
    pkgs.caddy
    pkgs.flyctl    
    pkgs.hugo
    pkgs.scour
  ];
  srcs = [ theme ];
  buildPhase = ''
    mkdir -p themes && [ ! -L "themes/nix-theme" ] && ln -s ${theme} themes/nix-theme
  '';
  shellHook = ''
    eval $buildPhase
  '';
}

This last shell.nix bit allows you to play with all of this in nix develop. Since this affects one’s local filesystem, and overwriting symlinks involving the nix store will be permission denied, it tests for the presence of the themes/nix-theme symlinked directory before trying to create a symlink. From in here, running huge serve will let you develop with the hugo server. I’m not 100% sure this is the best idea, but it worked well for me tonight.

Lastly, remember to .gitignore your dynamically built folders:

result/
themes/