Why
The production deploy fails at attach resolution:
✗ Attach target 'uptime-status' has no reachable box for 'production'.
Is 'uptime-status-production-app' provisioned (by its owner)?The box is running and reachable. Everything measured on the runner says the failure is inside buddy's code path, not this app's config:
| Check | Result |
|---|---|
HCLOUD_TOKEN from the secret | len 64, fp a0db7510b311 |
Same token decrypted from .env.production | identical |
Same token after @stacksjs/config loads | identical, not ciphertext |
.env written by the preflight | 121 lines, no HCLOUD_TOKEN line, so nothing clobbers it |
| The exact label selector buddy sends, run from the runner | 200, returns statushq-production-app |
| Committed cloud state that could short-circuit | none |
Replicating resolveAttachTargetBox verbatim, including its pick(), returns publicIp: 167.233.116.134. Buddy's own copy returns nothing.
What this changes
stacks ^0.70.366 caps at <0.71, so the app could never pick up any of the work done in that function since. This moves it to ^0.72.24, bringing buddy 0.72.24 and ts-cloud 0.8.3.
The relevant rework: 0.70.366 calls hetznerBoxIpv6?.(), and current source carries a comment explaining ts-cloud no longer exports that name, so the optional call silently yielded undefined. 0.72.24 replaces it with normalizePublicIpv6 and adds a re-resolve path that 0.70.366 lacks entirely.
Honest uncertainty
I cannot promise this fixes the attach failure. The documented change in that function is about IPv6 and AAAA records, not about a missing publicIp. But testing against current code is the prerequisite to filing upstream, and filing against a version two minors stale would rightly be closed as such.
Validation
tsc --noEmit: clean- Tests: 70 pass / 22 fail across 92, measured on
mainand on this branch with the same command. Identical, so the 22 are pre-existing and this upgrade introduces no regressions.
Not done here
Deploying. If the upgrade does fix resolution, the next deploy stops being a no-op and actually ships onto statushq's shared box, which still needs two answers first: whether 3042/3043 are free there (ts-cloud#168), and whether its owner is happy hosting loghq's log volume.