Container identity survives a redeploy
Docker containers were keyed on their container ID. A redeploy issues a new ID, so anything attached to the old row — your notes, your tags, the first_seen date telling you how long that service has been running — could be stranded on a record Homedex had quietly written off.
This came out of the r/golang Small Projects thread, where I raised the two connectors disagreeing about what a container's identity is as an open problem. Two things turned up that are worth stating plainly, because the obvious diagnosis was wrong:
A same-cycle recreate was already handled. An image bump between two scans kept its row, its notes, and its first_seen — the reconciler already adopted the row and re-keyed it. The real failure was narrower: if a scan ran while the container was down, the row was marked gone, and the adoption path skips gone rows. compose down, a scan, then compose up produced a second row and stranded the first along with its notes.
Keying is not why a host scanned by two sources lists things twice. Rows are unique per (connector, natural_key) by design, so each source keeps its own independent view and one source going away can never mark another's services gone. Two sources watching one host still list its containers twice, and making the key strings match would not change that. That is a display question, and it is untouched here.
- Containers are keyed by name, not ID. A name is unique per daemon and a recreate reuses it, so the record — and everything you hung on it — stays put across redeploys and outages.
- The compose service name is not the identity. It looked like the tidier choice, but
--scale web=3gives three live containers the samecom.docker.compose.service, which would collapse them into one flapping row. It remains the display label; the container name does the identifying. - Both collectors now agree. Docker and SSH both key a container as
<host>:<container name>. The SSH collector already read{{.Names}}; Docker has been brought in line with it. - Ports carry their metadata across the re-key. A port's key is derived from its service's, so this change moves every port key once. Ports are now matched by what actually identifies them, so the rows and their notes survive instead of being deleted and recreated.
- Upgrading is silent. The first scan after updating re-keys every existing container. That is bookkeeping, not something that happened in your homelab, so it is not written to the change feed — no wall of "recreated" entries against every service you own. A genuine redeploy still reports, through the image, tag, digest, or state that moved with it.
No migration and no action required. The first scan after upgrading re-keys existing records in place.
Not included
Hosts scanned by both a Docker source and an SSH source still list their containers twice. That is per-source isolation working as designed, not the keying bug; merging those views is a separate piece of work.
Also in this release
- Patched the
nanoidandpostcssadvisories in the dev toolchain. Production dependencies remain at zero advisories.
Container images are published to ghcr.io/harshshah0203/homedex.
See the upgrade and backup notes before replacing a running instance.