CrowdSec bouncer needs to be updated to 0.9.2

[shindouj]

Which Caddy modules need to be updated?
There is a new version of the CrowdSec Bouncer module that fixes a bug which makes it impossible to start Caddy: see hslatman/caddy-crowdsec-bouncer#84

Which existing Caddy custom build are you using?
I am running the build caddy-cloudflare-ddns-crowdsec-geoip-security-dockerproxy.

Additional context
Right now, it seems it is impossible to run setups with CrowdSec bouncer that configure the API key through Docker Proxy.

[nightshark]

I have this issue too.

[asieduernest12]

same too, in prod and local dev, everything was working fine.
i had a pined version of serfriz/caddy-crowdsec-geoip-ratelimit-security-dockerproxy:2.10

[serfriz]

Hey, sorry for the delay, I recently became a father, and my free time isn’t quite what it used to be. I’ve forced a rebuild of all Caddy builds that include the CrowdSec module, so they should now contain the latest version of the module. Please let me know if that resolves the issue. Thank you!

[asieduernest12]

@serfriz congratulations, didn't mean to pester.

[asieduernest12]

@serfriz feel free to respond at your best time,

the build for serfriz/caddy-crowdsec-geoip-ratelimit-security-dockerproxy:2.10 works now for me locally
what i noticed on hub.docker is that a couple hours ago the latest build for this exact image:tag was submitted 11 days ago

now with your latest build: that same image:tag is showing as submitted about an 1 hour ago as of writing this.

this breaks my understanding of tag, If i pin some image to tag x, i dont expect tag x to ever change in a billion years,
how ever tag latest can change as many times as you want.

Hopefully this issue is just a minor problem to your push process at least to configure tags and not over write old tags.

However if you actual design is to overwrite existing tags then you may be breaking so many projects who will not notice that their tags have changes without them realizing.

I would be most happy assist in reviewing your tag process especially if it is just updating some ci process to auto tag appropriately and push without overwriting old tags in various registry.

I have only observed this issue witth docker registry so there is that...

Here is some evidence of is the build tags not following the expected behaviour by looking at the tags of each build

REPOSITORY TAG IMAGE ID CREATED SIZE
serfriz/caddy-crowdsec-geoip-ratelimit-security-dockerproxy 2.10 9f0c318b5409 3 hours ago 116MB
serfriz/caddy-crowdsec-geoip-ratelimit-security-dockerproxy 2.10 157765eb51b0 2 months ago 116MB

[serfriz]

Hey @asieduernest12 the answer is that the tags refer to the Caddy version that the images are built with, but also each modules (in this case Crowdsec) may have different versions and that is what happened here. The image built 11 days ago was built with Caddy 2.10 and the version of CrowdSec available 11 days ago while the image built today was built with the same Caddy 2.10 (so same tag) and the latest version of CrowdSec as of today with has the fix to the issue you guys were having.

That is why all images are rebuilt automatically on the 1st of each month, to update them with the latest version of the modules even if the Caddy version is the same.

[asieduernest12]

@serfriz lets agree to disagree, this is a bad design,

I propose that you add a date sufiix to the end of each build tag so example

• serfriz/caddy-crowdsec-geoip-ratelimit-security-dockerproxy:2.10-2025-06-01 bleeding edge only on this date
• serfriz/caddy-crowdsec-geoip-ratelimit-security-dockerproxy:2.10-latest bleeding edge of 2.10 based builds
• serfriz/caddy-crowdsec-geoip-ratelimit-security-dockerproxy:latest bleeding edge, can be daily or weekly or hourly

this way i can pin a specific tag that works today and i know for the next billion years, It will never change,
if i want latest for 2.10 each month then i pin my tag to 2.10-latest or the latest of what ever version of caddy and its sub modules.

i will draft a pr fix for the github actions soon which should be piece of cake, realistically this is a good solution meaning everyone has the option to choose what flavor or version they prefere, they can pick the dated tag version and know it will never change or they can pick the un-dated tag x version of caddy build and that can change or they can decide they always want latest no matter what.

[serfriz]

Thanks for the suggestion, I'll consider it and it shouldn't be hard to implement adding a few lines to GitHub Actions. The downside I see are that for people that use :latest (o no tag) which is most people, every month they will see an update that possibly won't have any changes at all.

Another alternative is to stop building monthly images and just build them after new Caddy releases. If any module is incompatible with new Caddy releases at release date, eventually people will open a GitHub issue and I will be able rebuild the image if the problematic module has been fixed at that time.

[asieduernest12]

awesome

[nightshark]

@serfriz Congrats!

I agree with @asieduernest12. I also, have not seen a docker image operated like quite like you are.

[shindouj]

@asieduernest12 Just FYI, you can always "pin a version" of any container by using its SHA instead of a tag. Tags are mutable by design in Docker, so if you want a 100% guarantee that your container will not change, you should do that.

However, I do agree that there should be short hand "immutable" tags as best practice. What @serfriz does is nothing unheard of - named tags often change as well (e.g. Python's base image - numbered tags like 3.13-alpine are not a concrete version). The easiest solution here is to keep 2.10 mutable as is (keeps the current behaviour) AND add an additional tag, like 2.10-1, where -1 would increment with every automatic rebuild.

My honest suggestion, by the way, would be to also introduce daily rebuilds. With the above, anyone irritated by them can just use the image tag with dash. I am happy to look into both of the changes and prepare a PR for you next weekend since parenthood sure takes away lots of time. Sounds good?

[asieduernest12]

@asieduernest12 Just FYI, you can always "pin a version" of any container by using its SHA instead of a tag. Tags are mutable by design in Docker, so if you want a 100% guarantee that your container will not change, you should do that.

However, I do agree that there should be short hand "immutable" tags as best practice. What @serfriz does is nothing unheard of - named tags often change as well (e.g. Python's base image - numbered tags like 3.13-alpine are not a concrete version). The easiest solution here is to keep 2.10 mutable as is (keeps the current behaviour) AND add an additional tag, like 2.10-1, where -1 would increment with every automatic rebuild.

My honest suggestion, by the way, would be to also introduce daily rebuilds. With the above, anyone irritated by them can just use the image tag with dash. I am happy to look into both of the changes and prepare a PR for you next weekend since parenthood sure takes away lots of time. Sounds good?

@shindouj thanks for highlighting that Sha Pointer option. The approach @serfriz uses makes the hash worthless because the resources the has points to become overwriten and no longer exist once a rebuild is performed.

Either ways I haven't tried the has trick but I did lookup the previous hashes on the quay repo. The has id's exist but the files they reference no longer exist.

Docker hub seems to delete the history of the specific tag related Sha once the tag is overwritten. So the sha trick wouldn't even work as it stands presently.

I agree with your suggestion of daily builds.
The simplest approach I think @serfriz could utilize it the
'docker tag [image]:[version]-latest [image]:[version]-$(date -Imin)'

Then 'docker push -a' will push all the tags. So the presently mutable tags will continue to behave the same as they have always behaved. In addition a dated tag is also created which will not be mutable through ci because the dates tag command will just Create a new tag with a new timestamp accurate to the minute or I believe you could use 'date -Iday' to get a date string.

This approach of just making an extra tag just reuses the latest build. Maintains all current tags. And adds an extra tag that is pinned to a given date.

With this approach. Nightly builds would work perfectly too with no sweat practically.

At least I hope.

[shindouj]

@shindouj thanks for highlighting that Sha Pointer option. The approach @serfriz uses makes the hash worthless because the resources the has points to become overwriten and no longer exist once a rebuild is performed.

Either ways I haven't tried the has trick but I did lookup the previous hashes on the quay repo. The has id's exist but the files they reference no longer exist.

Docker hub seems to delete the history of the specific tag related Sha once the tag is overwritten. So the sha trick wouldn't even work as it stands presently.

This is only an issue if you didn't use SHA in the first place. Once downloaded, the image identified in the SHA will be in your local cache, and even if it gets overwritten remotely you'll be good to go.