Fly team, our dashboard reports hardware failures affecting vibo-staging-artifacts in GRU. At 2026-10-19 15:19:59 UTC, the native full Machines inventory returned 34 Machines; these five required image-retention Machines still had host_status=unreachable and no full config:
7847905a507058
0807799a9014d8
287e356fe9d908
0807562cd93508
0807562cdd9938
They are intentionally stopped image-retention holders, including an image from an existing trial. Four of the original nine affected holders have recovered. All nine required holders remain present. The incomplete inventory prevents our normal hosting-cost worker from producing current authoritative spend evidence, so our invite-only beta trial remains stopped.
Can Fly restore these hosts, or perform provider-managed migration while preserving the existing Machine IDs, image digests, full configuration and metadata? Please preserve the intended stopped state and do not delete, recreate, scale, redeploy, change image pins or run application workloads as a workaround. If same-ID recovery is not possible, please tell us the available preservation procedure and recovery estimate before taking a destructive action.
Our beta deadline is October 20. This request approves no paid support subscription, additional resources or billable recovery work. No credentials or user data are included.
Update (2026-10-19 15:46 UTC): authenticated, read-only registry queries successfully returned the exact immutable image manifests associated with all five holders, including the original trial image. Image layers were not downloaded or independently verified, so this is not a claim of a complete image backup. No holder, pin, image or workload has been changed.