Multi-host management (v2.0)

[amayer1983]

Tracking issue for v2.0's multi-host feature — one Docksentry instance managing several Docker hosts.

Use cases (collected from #2 + offline feedback)

• @famewolf: 3 Proxmox servers each running a Docker host in an LXC container. Currently running 3 separate bots (one per host) as a workaround.
• @adrianejovir (Docksentry fork): also explored extending the bot toward multi-host territory.
• Several Hetzner / homelab folks: 1 main + 1 backup host setup is common.

Bridging pattern already shipped

v1.17.3 added BOT_LABEL so multiple Docksentry instances can share one Telegram group / Discord channel and be told apart by prefix (🖥 pve1 · …). That makes "one chat, many hosts" usable today — but you still maintain N bots, N containers, N update streams. Real multi-host means one bot, one instance, N hosts.

Likely scope for v2.0

• Per-host configuration: DOCKER_HOSTS=name1:tcp://host1:2375, name2:…
• Per-host state files (pending queues, update history with host column)
• Hostname column in Web UI tables + host selector dropdown
• Hostname prefix in Telegram / Discord / webhook notifications
• Per-host healthcheck for the Docksentry control plane itself
• Migration path from single-host installs (preserve existing state)

Open design questions

1. Connection method: TCP socket per host (with TLS / socket proxy), or SSH tunnel, or both?
2. State storage: one /data directory with per-host subdirectories, or one flat dir with host-prefixed filenames?
3. Authentication: single global TELEGRAM_ALLOWED_USERS, or per-host control?
4. Group operations: can a container group span hosts? (Probably not — adds complexity without clear use case.)

What would help

If multi-host is something you'd actually use, comment with:

• Your setup (how many hosts, OS, Docker / Podman, behind a proxy?)
• What you'd want to do "across all hosts" (e.g. /status all vs /status pve1)
• Anything you'd consider deal-breaker missing

The more concrete the picture before I start coding, the more likely v2.0 lands close to what people actually want.

[amayer1983]

Design input from @famewolf on the multi-bot command UX, via #2:

"it may be easier to tack on the bot you are sending commands to on the END vs at the beginning from a coding perspective ie /check [botname] or /selfupdate -[botname]"

Two related ideas worth capturing:

A. Target syntax — prefix vs suffix vs -target flag

Form	Pro	Con
Prefix pve1: /check	Reads naturally ("at pve1, check")	Telegram won't autocomplete because the message doesn't start with /
Suffix /check pve1	Clean, autocomplete-friendly	Collides with commands that already take an arg (e.g. /pin sonarr — is sonarr the container or the host?)
Flag /check -pve1 or /selfupdate 1.17.3 -pve1	Unambiguous; doesn't clash with existing argv positions	Awkward to type on mobile

pve1: /selfupdate 1.17.3 (prefix) and /selfupdate 1.17.3 -pve1 (flag) both look workable; suffix-without-marker is the loser because of arg collision. Worth deciding before the v2.0 command parser is written.

"This could be bypassed by making the computer emoticon show up in all outgoing messages but NOT requiring it in the BOT_LABEL"

B. Output-only emoji vs label-input emoji

Today's BOT_LABEL=🖥 pve1 requires the user to type the emoji into the env. @famewolf points out this is awkward to type back into a Telegram command if we later use the label as the routing key.

Proposed split for v2.0:

• BOT_NAME=pve1 — the routable identifier (alphanumeric, lowercase, no emoji)
• Optional BOT_ICON=🖥 — purely visual prefix on outgoing messages
• v2.0 multi-bot commands use BOT_NAME as the routing token (/check pve1 or pve1: /check)
• BOT_LABEL (current v1.17.3 behaviour) keeps working as-is for backwards compat — internally treated as f"{BOT_ICON} {BOT_NAME}" when those are set instead.

Captures the visual cue users want without making the routing key annoying to type.

Tagged for the v2.0 design phase.

[famewolf]

Please keep in mind docker host to host communication when designing this. One specific use-case I can think of is to prevent multi host users from hitting the docker limit on pulls without being logged in. Either we would need the ability to login to get around this or consider caching NEW images for 7 days like you offer caching old ones for backups. The reason would be to share them with other hosts on the same lan (findable from within the bot if they are all sending messages through the same one or sharing the same group?) The caching would also help in situations where dockerhub is down but one of the hosts successfully grabbed the image. I have personally hit the limit with watchtwr because I had my check time to low and it was hitting every 12 minutes instead of 12 hours but I think the limit is 200 or so pulls a day and if people have 10 docker hosts I could see them exceeding the limit. Selfupdate should also be kept in mind because if you have 10 docker hosts there is 10 downloads asis vs 1 and sharing it.

[amayer1983]

Captured, @famewolf — the pull-rate-limit angle is a real constraint for multi-host. Two notes:

For v2.0 (this issue):

• Image-sharing across hosts on the same LAN — interesting but architecturally heavy (registry mirror? content-addressable share via mounted volume? Docker save/load over network?). Worth its own design pass when v2.0 starts.
• "10 hosts × 1 selfupdate = 10 pulls" is the cleanest framing of the problem — easy to lose sight of without your concrete number.

Standalone v1.x candidate (separate from this issue):

• Docker registry authentication — supporting DOCKER_AUTH_CONFIG path or DOCKER_USERNAME/DOCKER_PASSWORD env vars to bypass the anonymous limit. Also helps single-host users with many private/quay images. Not multi-host-specific, doesn't have to wait for v2.0. Will spin up its own issue if it gathers any additional interest.

Thanks for the input — exactly the kind of design constraint that should land before I start coding rather than during.