Hello everyone. Extending caddy with custom plugins using the xcaddy utility is fun. But i wonder how does the distribution of
these custom binaries actually happens to work, in a production system?
By distribution system, i meant a standard and convenient way of
shipping custom Caddy binaries. Caddy on its own provides a way of
shipping on Debian systems using its custom repos:
But i wonder what kind of solution do people use, if they wanted to use
Caddy with a bunch of modules. Do we need to setup some kind of CI/CD solution to continuously build custom caddy binaries or…?
As for myself, i literally build Caddy in my workstation, and then i move the binary to my server using something like scp. But I’m not so sure how can i improve the situation.
I would be happy to hear what are the people’s solution for this situation. Thanks
The post got a little old but if you still need help. I’d probably move the build into CI and pin the Caddy and plugin versions. That way you can publish a versioned binary or Docker image and deploy the exact same artifact to each server. It’s also worth checking the resulting binary with caddy list-modules before releasing it.
Hey. Thank you! I think i end up with a solution similar to you. I’ve created a dedicated github repository that continuously builds caddy on demand, and returns the resulting binary as a release. Here is an example:
Then, i’ve written an script with Pyinfra, which deploys my custom caddy binary on my server.
I thought i can somehow use the Download Caddy page, which lists all the modules that are available. But it doesn’t seem to capable of adding more plugins. I’ve tried signing in the website, but it gives me an internal error.
Ah nice, that sounds like a pretty good setup! I’d probably stick with gitHub releases and Pyinfra then. Having a known-good binary to roll back to is worth keeping in mind too, especially if you’re updating several servers.
As for the Caddy download page, I wouldn’t worry too much about using it for automated deployments. Your own build pipeline gives you more control anyway. The login error is a bit odd though. Might be worth reporting separately if it’s still happening.