All the major features planned for the next release are finished, so Caddy 2.4 beta 1 is now available. Please try it out! We’re still polishing things to make it even better before the release candidates, and documentation will be updated later, but for now you can start using it:
If you or your company is sponsoring Caddy, you have access to my new Expert Caddy series of chapters, which goes into depth about Caddy and related topics that will help you make the most of your web server. If you’re not already a sponsor, sign up here:
Thank you for your ongoing support! It will allow me to continue working on Caddy full-time.
The self upgrade feature caught my attention. My reading of the release notes is that it will work with pre-built binaries as well as binaries built from source with additional packages. Is my interpretation correct? And this feature will work on any supported platform?
Yeah, the idea is it will read your current binary’s list-modules output to figure out which external modules were compiled in, then it’ll make a request to Download Caddy requesting a new binary with the latest version and the same external modules you already had.
If I were to script the upgrade command to run on a periodic basis, would it be possible to implement the following psuedocode?
If caddy was upgraded then restart caddy
If it were possible, what I’m trying to figure out is what status code should I look for after caddy upgrade runs that indicates the command ran successfully and an upgrade actually took place, as opposed to, the command ran successfully, but no new version was installed?
I tried (unsuccessfully!) to figure it out by studying the code, and noticed several error conditions are checked for.
After a successful caddy upgrade, until Caddy is restarted, wouldn’t caddy version still give me the old version i.e. the Caddy instance that is presently running rather than the version of the binary just replaced?
If you use any commands that use the API, like caddy reload, then it would reload the currently running instance (old binary) by using the new binary to send the reload message, but commands like caddy version that just query the currently available binary, it’ll use the latest.
Here’s a version of a bash script that can be run periodically as a cron job to automatically upgrade Caddy 2.4.0 and above to the most current release of Caddy. It should run on FreeBSD systems and its derivatives like FreeNAS/TrueNAS. It implements the logic discussed in the last few posts of this thread and can probably be adapted for other Unix-like systems that also run Caddy.
if [ $status -eq 0 ]; then
if [ "$(caddy version)" != "$ver" ]; then
service caddy restart
echo "Something bad happened! Upgrade status=$status"
removed this banner . It will no longer appear at the top of every page.
I installed the 2.4.0-beta.1 static binary and then manually ran caddy upgrade. I had in my mind that the latest tweaks to beta.1 would be applied. The upgrade went through successfully. The only issue was that Caddy was downgraded to 2.3.0
It’s intentional that it upgrades you to the latest stable. Depending on how you define upgrade, changing from a pre-release to a stable release is an upgrade. I dunno. I’m not actually sure that is wrong?