Depot builds fail every time: "failed to list workers ... authentication handshake failed: EOF"

General
1

Since around 07:10 UTC on 14 Sep 2026, every Depot build for my app cabral-dev fails before the build starts. The last successful Depot build was release v593 at 05:38 UTC on 11 Sep.

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"

With LOG_LEVEL=debug, POST /api/v1/builds/depot_builder returns 200 with a build_id and build_token. flyctl then waits about 300s and fails:

DEBUG <-- 200 https://api.fly.io/api/v1/builds/depot_builder (1.81s)
DEBUG result image:<nil> error:error building: timed out connecting to machine: failed to list workers: Unavailable: connection error: desc = "transport: authentication handshake failed: EOF"
...
"timings": { "build_ms": 299995, "builder_init_ms": 20246, "context_build_ms": -1 }

What I’ve tried:

  • Reset the org builder under App Builders in the dashboard: no change.
  • --depot-scope app: same error. It also created a second builder that also fails.
  • A different network (mobile hotspot): Depot still hangs. No VPN or proxy is active.
  • Clock is in sync (0.2s offset).
  • flyctl v0.4.102 darwin/arm64. That’s the same version that built v593 successfully.
  • Deploying with an app-scoped deploy token that hasn’t changed since August.

The legacy remote builder (--depot=false) works from the same machine and network, so that’s my workaround for now.

Fly build IDs, in case staff can look them up: 39992666, 39993123 (org builder), 39993791, 39994395 (app builder; Depot build IDs tg3b0kkgj8 and htwqt4q2d8), 39995526 (org builder, over the hotspot).

The same error came up in these threads, which closed without an answer:

Is something wrong with the Depot builders for my org, and is there anything I can reset on my side?

2

Hey @ronaldorp! Thanks for bringing this up, we’ve created an incident for this and our team is currently investigating what’s occurring. As you mentioned running with --depot=false should work as a workaround at the moment :slight_smile: