Caddy 2.4.0 beta 1 is now available

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:

:newspaper: Release notes and :arrow_down: Download

New content for sponsors

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. :star_struck: 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?

1 Like

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.

1 Like

Will Caddy still be available throughout the upgrade or is there likely to be an interruption to service at some point during the upgrade?

I’m just wondering if the command should be run manually under controlled conditions, or, running the command automatically on a periodic basis will be fine.

1 Like

No interruption, because all it does is swap out the binary. You will need to restart the Caddy process for the upgrade to take effect. See the code:


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.

You could do it yourself by assembling a cron job that tries to upgrade, then checks the last updated time of the file to see if it was recently updated, and if so restart.

I don’t think that will be built-in to Caddy because Caddy is cross-platform and the procedure for that is different depending on how you run it.

1 Like

Exit status 0 means success, then caddy version will tell you the new version. If it’s different from before, then a different version was installed.

1 Like

Thanks @francislavoie and @matt. That gives me some ideas to work with.

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?

No. The old binary won’t exist anymore so it will have to run the new one.

1 Like

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.

ver=$(caddy version)
caddy upgrade
if [ $status -eq 0 ]; then
  if [ "$(caddy version)" != "$ver" ]; then
    service caddy restart
  echo "Something bad happened! Upgrade status=$status"