[Feature] podman support, maybe just some notes?

[LeeNX]

What would you like Docksentry to do?
I would like to use this pretty tool with podman

Why is this useful?
Would help me manage 3/4 of my container hosts

Possible implementation (optional)
Can use the basic docker api, but there are some difference that would need to be addressed as they come up

Your setup

• Docksentry version:
• Notification channels used: Telegram / Webhook
• Deployment: Docker Compose / Podman Compose / Podman Systemd

[amayer1983]

Thanks for the request — Podman support has come up internally as a "someday" thing but you're the first user to actually ask for it, which moves it from theoretical to concrete. Before I commit to anything I want to be honest about scope, because Podman is three fairly different deployment paradigms behind one name:

Setup style	How close to Docker?	What we'd need
Plain podman run	Very close — podman CLI is mostly a drop-in for docker	A CONTAINER_CLI env var so we call podman instead of docker. ~50 LOC, decent hit rate
Podman Compose	Close — podman compose honors docker-compose.yml syntax via shim	Same env-var swap; tests will show edge cases
Podman Systemd / Quadlets	Completely different paradigm — containers managed by systemd, update cycle is .container file edit + systemctl restart, not docker stop + docker run	A separate update flow. Bigger architecture lift, probably not v1.x material

To know what's actually worth building, three quick questions:

1. Which mode are you on? You listed all three — I'm guessing one is your dominant setup and the others are aspirational. Which one would I be building against?

2. Rootful or rootless Podman? Matters because rootless changes socket paths, /etc/hostname resolution, and some of the self-detection logic (Docksentry's #16 PID-1-self-kill guard relies on cgroup-derived container IDs that behave differently rootless).

3. Are you up for being the test pilot? I don't have a Podman host to verify against — Docksentry's CI builds and runs only on Docker. If we ship a CONTAINER_CLI=podman toggle, you'd be the person finding what breaks. Reasonable expectation: I ship an experimental v1.18.x, you try it, file issues for each thing that doesn't behave, we iterate.

If you're on plain podman run or Podman Compose and game for the test-pilot role, I'd target it for v1.18.7 next week. If your 3-4 hosts are Quadlets/systemd-managed, that's a different beast and would slot into the v2.0 multi-host design over in #7, since the "manage containers without owning their lifecycle" problem overlaps with what multi-host needs to solve anyway.

Either way — appreciate the issue, just want to set the right expectation before promising "Podman support" in the CHANGELOG.

[LeeNX]

Thanks for the request — Podman support has come up internally as a "someday" thing but you're the first user to actually ask for it, which moves it from theoretical to concrete. Before I commit to anything I want to be honest about scope, because Podman is three fairly different deployment paradigms behind one name:

Yeah, top post or at least first request for podman. So showing my age.

Thank you @amayer1983 for the quick reply.

Setup style How close to Docker? What we'd need

1. Which mode are you on? You listed all three — I'm guessing one is your dominant setup and the others are aspirational. Which one would I be building against?

I prefer using podman-compose, even for jumping into containers, just way easier keeping all the options together in a compose.yml file, thou I also use the podman run to quick once-off tests, but I don't think this would be a use case for dockSentry.

2. Rootful or rootless Podman? Matters because rootless changes socket paths, /etc/hostname resolution, and some of the self-detection logic (Docksentry's #16 PID-1-self-kill guard relies on cgroup-derived container IDs that behave differently rootless).

I am aware of some of the differences between rootful and rootless podman has, I have run into some of these edge cases when setting up my dozzle farm, but I was not aware of the above tricky parts. Sounds interesting, but I am not sure if I can help there, but totally willing to poke at and report anything I can.

3. Are you up for being the test pilot? I don't have a Podman host to verify against — Docksentry's CI builds and runs only on Docker. If we ship a CONTAINER_CLI=podman toggle, you'd be the person finding what breaks. Reasonable expectation: I ship an experimental v1.18.x, you try it, file issues for each thing that doesn't behave, we iterate.

I am happy to help where I can. Treat me like your crash-test-dummy. I have some basic skills and a pretty odd ball setup of docker hosts to more podman hosts, ranging from x86-64 boxes to many SBC like Raspberry Pi 3 to 5 and even a few RockPi 4.

If there is a basic cli way to test features and a public container I can pull test releases from, I should be able to give feedback and I hope others might find it useful. Might even have to rename dockSentry to containerSentry ... ;-)

If you're on plain podman run or Podman Compose and game for the test-pilot role, I'd target it for v1.18.7 next week. If your 3-4 hosts are Quadlets/systemd-managed, that's a different beast and would slot into the v2.0 multi-host design over in #7, since the "manage containers without owning their lifecycle" problem overlaps with what multi-host needs to solve anyway.

I am keen and think starting with the low hanging fruit is a good way forward. The quadlets containers have the autoupdate, but I would prefer the more bells a whistles that dockSentry offers, but understand it's a big ask with limited resources.

Either way — appreciate the issue, just want to set the right expectation before promising "Podman support" in the CHANGELOG.

You are welcome and thank you for what looks like is going to be an awesome tool. If anything, I was only expecting a note in the documentation, saying dockSentry might not work with podman in many setups or only works with podman-compose.

Please feel free to ping me as you need or I could help.

[amayer1983]

@LeeNX thanks for the detailed answer — podman-compose as dominant + willingness to test on multi-arch is exactly the signal I needed. While digging in I realised we don't actually need a CONTAINER_CLI env or a separate image for the first pass: Podman implements the Docker REST API natively, so mounting the Podman socket at /var/run/docker.sock is enough for most operations. Our existing Docker CLI inside the Docksentry container talks to Podman's API endpoint and gets back identical responses for containers/, images/, inspect, etc.

Shipped that as a documentation section in v1.18.11 — no code changes yet, just clear setup instructions + honest expectations.

Setup TL;DR — rootful Podman:

sudo systemctl enable --now podman.socket

services:
  docksentry:
    image: amayer1983/docksentry:latest
    volumes:
      - /run/podman/podman.sock:/var/run/docker.sock:ro
      - docksentry_data:/data
    environment:
      - WEB_UI=true
      # ... rest of your config

Rootless: same shape, swap the socket path to /run/user/1000/podman/podman.sock (or your $UID).

What I expect to work: /status, /check, /updates, pulls, lifecycle commands, container groups, the v1.18.10 17-field HostConfig recreate.

What I expect to break first:

1. Rootless #16 PID-1 self-protection — we read cgroup paths to identify our own container, those layouts differ rootless
2. podman-compose label format — slight variations from Docker Compose's labels; we might miss compose-detection and fall back to standalone recreate
3. Multi-arch: our image is amd64 + arm64. Pi 4/5 should work. Pi 3 is armv7, not currently built — let me know if that becomes blocking for you

Test plan, in priority order:

1. Get the WebUI loading + /status from Telegram → confirms socket + auth works
2. Run /check against a few of your podman-managed containers → confirms inspection works
3. Pick a low-stakes container, manually trigger an update → confirms pull + recreate works
4. If self-update interests you, try /selfupdate last — that's the most invasive path

For each thing that breaks, open a separate issue with:

• Podman version (podman --version)
• Rootful or rootless
• Architecture (uname -m)
• The exact error (Telegram message, docker logs of Docksentry, etc.)

Targeted issues let me ship targeted fixes; "Podman doesn't work" is too vague to act on.

Might even have to rename dockSentry to containerSentry … 😉

If the experimental setup pans out for enough Podman users, I'll seriously consider it. For now I want to see what actually works before committing to a brand change. Appreciate you being patient — back to you for the first round of testing.

[LeeNX]

Thanks @amayer1983 ... A little bit of quick feedback.

Started my first dockSentry instance, worked with few corner cases, I will open an issue for them, but quoted envs, which look better but broke usage.

Started second instances on my x86-64 podman server, that mostly has podman-compose containers, basically works, as in it started up. There are a few things that could be improved, but at least started. I will open issues that we can work though. Other environments to follow.

Having telegram on two servers, should I do a hub/agent setup or am I missing something else? I did give each instances their own - BOT_LABEL=🖥 -cylon-

docksentry    | Telegram API 409: Conflict: terminated by other getUpdates request; make sure that only one bot instance is running

[amayer1983]

@LeeNX two things:

On the 409 conflict — that's a Telegram API hard rule: one bot token = exactly one polling instance. Two Docksentry instances sharing TELEGRAM_BOT_TOKEN will fight over getUpdates and one of them gets evicted with a 409 every poll. BOT_LABEL is just a display prefix in the messages each bot sends; it doesn't change the underlying Telegram bot identity (the token is the identity).

Fix: create a second bot in @Botfather (/newbot), give it a distinct name, and use its token in your second Docksentry instance. Both bots can live in the same Telegram group — that's exactly the Famewolf-style multi-bot setup the BOT_LABEL feature exists for. Each instance polls its own token, no conflict, and you can address them individually with /status@bot1 vs /status@bot2.

# host A
environment:
  - TELEGRAM_BOT_TOKEN=<bot-A-token>
  - BOT_LABEL=🖥 cylon

# host B
environment:
  - TELEGRAM_BOT_TOKEN=<bot-B-token>
  - BOT_LABEL=🥧 pi-rack

On hub/agent setup — currently doesn't exist. A central Docksentry-bot on one host receiving status from agents on other hosts would be a sizeable architecture change (registration, mTLS, message queue or webhook reverse-connect, agent-side feature subset). I've noted it as a possible v2.x direction, but I'd want to see several Podman/multi-host users explicitly ask for it before committing — multiple-bots-in-one-group is the lighter-weight path that already works.

Also: v1.18.12 just shipped fixing the health-status bug you reported in #28. Worth pulling before you continue testing — fewer confused icons.

[LeeNX]

Thanks @amayer1983!

I now understand the Telegram limitation, might be worth adding some info to the docs about a telegram bot per host. I read multi-bot-setup-one-group-multiple-hosts as that just needed a unique BOT_LABEL per host.

I think I am just going to use Gotify with webhooks or something, but the WebUI is ok for this podman host.

Thanks for the info on the hub/agent, I did see that on the roadmap or possibly planned and bot per host is not a big ask.

Now to see if any release come out with updates to see if we get any errors.

[amayer1983]

@LeeNX fair feedback — re-reading the section with fresh eyes you're right, "distinct BOT_LABEL" was the only checklist item that jumped out, even though the YAML examples did show different tokens. That's exactly the kind of "doc says it but doesn't say it" gap that bites.

Tightened the Multi-bot section in v1.18.13 — now:

• Up-front note explains why each host needs its own BOT_TOKEN (one token = one polling consumer, hence the 409; BOT_LABEL is only a visual prefix, not an identity).
• Setup checklist now leads with "run /newbot once per host" as step 1, and the final configure step spells out distinct BOT_TOKEN + distinct BOT_LABEL + same CHAT_ID.

Re Gotify with webhooks for notifications: that's a totally reasonable split — Docksentry's webhook output (env: WEBHOOK_URL) sends a JSON payload Gotify can consume directly, so you get Docksentry notifications without keeping the Telegram bot polling at all. The Web UI on the Podman host stays for inspection/actions, and Gotify handles the "tell me when something happened" channel. No bot-per-host friction for the notifier side.

Leaving this open for your continued testing — and looking forward to the issues for the corner cases you mentioned (quoted-envs, the small improvements).

[LeeNX]

Thanks @amayer1983 ... Added a few features request issues, one might need to be change to bug investigation, but I am away this coming week and will have very little access to my caveLab, so I don't think I will be able to give much feedback. Please feel free to poke me on any of the issues that might be lacking enough info to move forward.