max / alloy

Ship avahi-tools so an Alloy box can resolve its own .local avahi-daemon publishes <name>.local on every install and nothing on the machine could ask whether that worked: the resolve side had to be checked from another host. With Tailscale out of the minting path and installs LAN-only, ssh installer@<name>.local is the install flow, so its failure mode was invisible exactly where it matters. Named explicitly for the same reason avahi itself is, per alloy@db989d9.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

Author: Max Johnson <me@maxj.phd> · 2026-08-16 23:22 UTC

Signed with PGP, not checked

Commit: ee6b15fa4f854f6bc6ef12e9708a60ce4d770f52

Parent: 7c27f87

1 file changed, +8 insertions, -0 deletions

M Containerfile +8

			@@ -832,7 +832,15 @@
832	832		# so it is not competing for UDP 5353; setting it to `yes` would break
833	833		# avahi rather than add anything, since only one process can hold that
834	834		# port.
	835	+	#
	836	+	# avahi-tools is the third half: `avahi-resolve` and `avahi-browse`, so a
	837	+	# machine can check its own mDNS rather than needing a second machine to
	838	+	# check it from. With Tailscale out of the minting path and installs
	839	+	# LAN-only, `ssh installer@<name>.local` IS the install flow, and its
	840	+	# failure mode is invisible on the box that is failing. Named explicitly
	841	+	# for the same reason as avahi above: nothing else pulls it in.
835	842		avahi \
	843	+	avahi-tools \
836	844		nss-mdns \
837	845		# podman, the runtime behind two of `alloy pkg box`'s three isolation
838	846		# levels: `workspace` calls it directly and distrobox wraps it for