Recommended upgrade options

[anantshri (Anant Shrivastava)]

Hi Team,

1. The problem I’m having:

I am new to caddy. I am trying to build a custom caddy binary and worried about its upgrade path.

2. Error messages and/or full log output:

Not applicable need guidance

3. Caddy version:

v2.7.5 h1:HoysvZkLcN2xJExEepaFHK92Qgs7xAiCFydN5x5Hs6Q=

4. How I installed and ran Caddy:

1. Installed caddy via debian bookworm repository
2. Followed instructions Build from source — Caddy Documentation to setup caddy.custom
3. I have put caddy.custom using xcaddy command as listed below

xcaddy build \
	--with github.com/caddy-dns/route53 \
	--with github.com/greenpau/caddy-security \
	--with github.com/greenpau/caddy-git \
	--with github.com/caddyserver/replace-response

a. System environment:

Debian Bookworm
x64
direct deployment via systemd using official package

c. Service/unit/compose file:

Standard compose file

d. My complete Caddy config:

Not relevent

e. My question

However now i am concerned about a few things. since i have taken over the binary as i needed these custom plugins. How do i ensure i am not missing on upgrades.

there are lots of thread and all of them confusing. so making another thread to hopefully get some good answers or add more to the confusion.

Here is what i am thinking and need suggestions if i am doing right.

Idea 1: since this is custom build, i can simply do caddy upgrade command as a daily cron and if it builds binary successfull, restart caddy
Idea 2: setup a monitoring script for releases on all my plugins and caddy itself and if anyone does an upgrade i should build it automatically.
Idea 3: Be less paranoid and wait for specific security bugs and then only upgrade otherwise let it be.

Do suggest if anyone has tried any of these approaches or something else. effectively how do you keep caddy up to date. or do you even worry about it.

[francislavoie]

IMO automated/unattended upgrades are not a good idea, because there’s no guarantee that a new version won’t have breaking changes.

I recommend you sign up for release notifications on GitHub. Go to GitHub - caddyserver/caddy: Fast and extensible multi-platform HTTP/1-2-3 web server with automatic HTTPS, and in the top-right click Watch and select Custom and check only Releases.

Doing it manually ensures that when you do upgrade, you’ll always be at the ready to fix any errors that might come up caused by the upgrade.

Keep in mind that the GitHub release is the first thing we do when we make a release, it can take a bit of time (usually only minutes, sometimes longer depending on certain factors) for caddy upgrade to actually pull the latest version.

[anantshri (Anant Shrivastava)]

Hey Francis,

Thanks for the response.
I am worried about hypothetical scenarios where if i am not around for say a week and a security bug comes in so far i am happy with unattended-upgrades on debian handling these for me. but with caddy I am in unknown territories hence looking for options.

I do agree manual works the best but afraid of the above scenario.

[francislavoie]

It’s extremely rare that there’s security releases that are that critical. IMO it’s not worth worrying about it that much. As long as you don’t fall months behind on releases, you’ll be fine.