Organization API slug: davide-palmer; affected app example: palmeros. Since approximately 2026-08-30 23:05 UTC, all Depot builds hang at “Waiting for depot builder.” Direct testing on 2026-08-31 01:27–01:41 UTC shows Fly returns build assignments immediately and Depot reports them active, but app scope (z13pz8ts5v) and org scope with explicit fly-ord (g026mcfv9h) both receive 149.248.212.172:443. TCP connects successfully, but an mTLS handshake using Depot’s issued server name, CA, client certificate, and key is closed by the remote side with UNEXPECTED_EOF_WHILE_READING; a gRPC channel never becomes ready. --depot=false works. Please inspect the org’s Depot ingress/certificate/SNI routing and the service behind 149.248.212.172:443.
Second org seeing this, same window - so it isn’t scoped to davide-palmer.
Org personal, app igpt (sjc). Every GitHub-integration deploy has failed since 2026-08-30 ~23:45 UTC:
==> Building image
Waiting for depot builder...
error releasing builder: deadline_exceeded: context deadline exceeded
Error: failed to fetch an image or build from source: error building: timed out connecting to machine: failed to list workers: Unavailable: connection error: desc = "transport: authentication handshake failed: EOF"
Deterministic - two 5-minute builder waits, then hard fail. Three attempts: deployment 1966654 at 00:12 UTC (646s), 1966759 at 00:46 (648s), 1966842 at 01:13 (650s). 1966842 was a dashboard retry, so it isn’t a stale webhook.
flyctl deploy --remote-only --depot=false succeeds immediately on the identical commit and Dockerfile - matching your “classic builds work” discriminator, the same handshake EOF, and the same start window.
Ruled out on our side: GitHub integration healthy (repo attached, auto-deploy on, branch main), status.flyio.net and status.depot.dev both green, no fly-builder app in the org to recycle.
The fly-builder-* apps are the “classic” builders, though…
There’s a separate reset procedure for the Depot builders:
You can also move it to a different region, like it says there, in case it’s a capacity crunch in sjc overall (which seems plausible).