Using nix to replace xcaddy to build Caddy webserver

I found the Caddy webserver and I now want to play around with building a nix package that allows me to build caddy with overrides for the different caddy modules. Similar to what the custom build tool the caddy devs used named xcaddy: GitHub - caddyserver/xcaddy: Build Caddy with plugins.

When you run xcaddy with: xcaddy build --with

You get a main.go and go.mod that contain the following:

package main

import (
        _ "" # This is the caddy moudule for cloudflare dns
        caddycmd ""
        _ ""

func main() {
module caddy
go 1.15
require ( v0.0.0-20210227191100-728f5b67d095 v2.4.0-beta.1

it then runs:

go mod tidy
go build -o caddy -ldflags "-w -s" -trimpath

And that builds a caddy webserver with the cloudflare dns module enabled. You can additional caddy modules by just adding more --with flags that point to caddy module repositories.

My goal would be to replace the xcaddy tool with a nix program. I imagine it will start by forking the caddy form nixpkgs: nixpkgs/default.nix at 6040ffb45f78c66ecedcbcb82fed58bacec71198 · NixOS/nixpkgs · GitHub and add some overrides that use main.go and go.mod templates that will be populated with the overrides that get passed to it. Any suggestions about this are very much welcome! (this is kinda what I’m fishing for)

Another reason I want to do this is because I think xcaddy is basically doing the oppsite of the “nix way” and it just feels very uncomfortable to put it in my nix workflow since i can’t use GitHub - nix-community/vgo2nix: Convert go.mod files to nixpkgs buildGoPackage compatible deps.nix files [maintainer=@adisbladis] on the generated go.mod file and go.sum that xcaddy spits outs. It would basically have a different nix hash every time.

Thanks for reading!


I ended up not using the xdaddy build tool with nix and I’m just using nix to build a goPackage with the imports.

So no dynamic caddy plugins yet.

Take a look at: GitHub - sbc64/nix-caddy: Caddy built with nix