There was an error while loading. Please reload this page.
Offer an address that works without a DNS name "Your Mac needs a real DNS name" isn't advice a home user can act on, so the troubleshooting entry now gives two alternatives instead of one, both checked on a live lab: the Mac's LAN address on the published port, which a container on any network can reach, and putting both services in one stack. The same run confirmed what the entry claims — a container on another network resolves fleetlab-fleet.test and gets no route to it, and a .local name doesn't resolve at all. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Follow through on the cross-network fix The lab I built put Gitea on Fleet's network, so I never hit what these instructions actually produce: two stacks, two networks, and a runner that resolves fleetlab-fleet.test and then can't route to it. Thanks to the clean-Mac run for finding it. The secrets section now says to use the Mac's own name; this carries that through the rest, which still assumed the container name was reachable: - Part 1 no longer claims local DNS is what gets the runner to Fleet. It buys a browser address and names within a stack, and explicitly not a route between stacks. - Fleet's own server URL is set to the same host name from the start. The workshop's default.yml sets server_url from FLEET_URL on the first run, so the old advice would have had it change underneath you. - The certificate uses the host name, with a note that self-signed means it needn't match anyway. - The untested machine-enrolment note carries the same warning. - Troubleshooting gains the failure itself, plus the two things that decide whether the fix works: the Mac needs a real resolvable DNS name, since containers don't answer mDNS, and failing that, putting both in one stack puts them on one network. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Updated Fleet GitOps Lab (markdown)
Add the Fleet GitOps lab walkthrough A Fleet server, a Gitea server with CI, and a runner that applies config to Fleet on every push — all in Apple containers, no Docker. Written from actually building it rather than from the upstream docs, so the failures are in it: fleetctl refusing a plain-http address, Fleet excepting enroll secrets from GitOps by default, the runner base image lacking node and perl, and the one that matters most — Fleet running happily for an hour on the default memory and then going silent when its vulnerability cron fires, with no error anywhere to explain it. Each is written next to the step that prevents it. Also records the two decisions a reader would otherwise get wrong: the compose file's certificate mounts have to exist even with TLS off, and mysql's x86 pin should go while fleet's should stay. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Correct what local DNS actually does Five pages said containers can't reach each other by name and that local DNS only helps this Mac. Both wrong once a default domain is configured: containers resolve each other as db.test and as bare db, verified with an HTTP 200 between two containers by bare name. Also records the distinction that caused the confusion — resolution is global, routing is per-network, so a name can resolve to an address you have no route to. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Refer to the upstream issue in plain text Matches the style used in the app's release notes. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Add user documentation Eleven pages plus a sidebar: a quick start that gets to a running web app, worked examples, a guide per section, and troubleshooting organised by the symptom rather than the subsystem. Written around the one constraint that explains most of the app's design — containers reach each other by address, not name — since coming from docker-compose without knowing that makes several behaviours look arbitrary. It's stated on the home page, explained under Stacks, and its limits are spelled out under Local DNS, which people will otherwise expect to fix it. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Initial Home page