[Feature] Add support for container labels to control options like protection

[LeeNX]

What would you like Docksentry to do?
Please could we support container labels for some or all configs setup or fixed overrides?

Why is this useful?
Trying to do as much in configs for gitOps like management. Keeping all the container setup in one place would be nice. Not sure that everybody would use this, but I very much prefer all my container setup in the same place. Way easier to track changes, thou the auto version update for containers is something I am not sure how to tie together, maybe a different feature request.

Possible implementation (optional)
an example of the container labels set.

    labels:
      - "docksentry.enable=true"
      - "docksentry.protect=true"

Your setup

• Docksentry version: v1.31.0
• Notification channels used: Telegram / Webhook
• Deployment: Docker run / Docker Compose / podman-compose

[amayer1983]

Shipped a first cut in v1.33.0. Docksentry now reads docksentry.* labels straight off your containers, and a present label overrides the equivalent bot/Web-UI toggle (so your compose file is the source of truth):

labels:
  - "docksentry.exclude=true"     # = docksentry.enable=false → out of update scope (like /pin)
  - "docksentry.protect=true"     # refuse /stop (=false force-unprotects)

Booleans accept true/1/yes/on. Lookups are best-effort — a failed inspect falls back to the stored toggle and never silently unprotects.

Two questions to shape where this goes next, since you live in GitOps land:

1. Opt-in mode? Right now Docksentry manages every running container except excluded/pinned/enable=false ones (opt-out). Would you also want a global "label mode" where it only manages containers carrying docksentry.enable=true (pure opt-in, Watchtower-style)? That would be a config switch (e.g. LABEL_MODE=opt-in).
2. Which other settings would you most want as labels next — docksentry.autoupdate, docksentry.cooldown=<sec>, docksentry.trust_running, update windows? Happy to add the ones you actually use.

Give the exclude/protect labels a spin on v1.33.0 and let me know.

[LeeNX]

Nice questions, but I am thinking my use-case is that I find most of the defaults good so far and only really need a few overrides, so I am thinking if you running dockSentry, I would prefer opt-out, but I am open to either.

I can't say what I need yet, as the protect is the only real label I would like to use. The three suggested labels I don't quite understand or see where they fit in. Did a quick look for what autoupdate is, but feel like I a missing something and maybe things have been moving so fast, that I don't think I have hit this use-case or pain point.

Thanks @amayer1983 , let me know if there is anything else I can help with.

[amayer1983]

Perfect, that keeps it simple. Opt-out is exactly the current default, and docksentry.protect=true (the one label you want) shipped in v1.33.0 — set it on a container and /stop is refused for it, overriding the toggle. The other labels were just optional extras; ignore them. Give protect a try and let me know it does what you need — happy to add more labels later if a concrete pain point shows up.

[LeeNX]

This is going to take a little while to test and confirm, got to find some projects that will update. Hope you don't mind if I keep this open for that.

[LeeNX]

I was updating my cloudFlare tunnels, making sure that "docksentry.protect=true" was put in place and was working and found that it's doing some random stuff, at least from my view.

Updated the following containers:

• cft-alt-latest
• cft-kb-even
• cft-kb-latest

Not updated:

• cft-alt-odds
• cft-kb-odds

So I expect the stop to be available for both odds, but this is not the case

With "docksentry.protect=true" in place for all latest and even contains, I would expect stop to be removed, but this is not the case either, as cft-alt-latest still has the stop button. I have stopped the container, removed and restarted and refreshed dockSentry and the current state is still in place.

This is an older docker host 28.1.1, running Ubuntu 20.40 on and ARM64 SBC. With Docksentry v1.38.1

[LeeNX]

Mmm, maybe the opt-out logic is switched, as my podman-compose host seems to have all containers stop removed? I have not added any of the "docksentry.protect=true" label yet.

[amayer1983]

Let's untangle this from #43 first — your Podman host was in the bricked/renamed state, so the Web UI may have been showing a half-broken picture. Could you recover it (steps in #43), get onto v1.38.2, and recheck?

On the logic itself: the Stop button is hidden only when a container is protected — i.e. it has a docksentry.protect=true label or the stored per-container toggle is set. With neither (your case), Stop should show. The opt-out logic isn't inverted — protect is strictly opt-in.

One likely culprit unrelated to protect: the Stop button also only renders for containers Docksentry sees as running. On Podman the running-state read has been finicky before (#28); if a container reads as not-running, you'd get a Start button instead of Stop, which could look like "Stop removed for all". So, once you're on v1.38.2, could you confirm:

1. Are those containers actually shown as running (or do they show a Start button)?
2. podman inspect --format '{{json .Config.Labels}}' <one-of-them> — anything docksentry.* in there?

That'll tell us whether it's a protect misfire or a Podman running-state read. Thanks!