its been 45 monutes. no status updates?
Same for me ( in ORD). Waiting for depot builder…, the globe spins, eventually errors out:
Error: failed to fetch an image or build from source: error building: deadline_exceeded: context deadline exceeded.
Please help
USE This instead in your terminal:
flyctl deploy -a {PROJECTNAME} --depot=false
ok that worked. they shoud fix that.
Thank you. A quick chat with your friendly LLM provided some context, for those who are curious about this --depot=false flag
Short version: --depot is a boolean flag that selects the build backend, and it now defaults to true. So --depot=false turns off Depot and sends your build to Fly’s older builder instead. That’s why you’re seeing Depot in your logs even though you never asked for it — it’s the default, and the flag just lets you opt back out.
Here’s the fuller picture.
What Depot is. Depot is a third-party accelerated container-build service that Fly partnered with. As of flyctl 0.2.102 you could opt in with the --depot flag to use Depot as the builder when deploying, and since then it’s flipped to being the default. Mechanically, flyctl connects to a Depot builder running as a Fly machine inside Fly’s own infrastructure, which processes the build and pushes the resulting image into Fly’s registry, after which Fly deploys it. Each builder is single-tenant so your org’s builds are isolated, and the layer cache is persisted to Fly volumes so subsequent builds can reuse it. It’s a BuildKit-based engine tuned for fast incremental builds — genuinely faster than the old path when it’s working.
What --depot=false falls back to. Fly’s legacy remote builder: a per-org fly-builder-* machine running Docker/BuildKit that flyctl talks to over WireGuard. It’s the mechanism that predates the Depot partnership. Slower cold-start and no cross-build Depot caching, but it’s a completely separate code path and infrastructure, which is the whole point of the workaround.
Why this fixes your error. Your failure is at the builder-acquisition stage, not the build itself — the classic pattern is repeated “Waiting for depot builder…” lines terminating in context deadline exceeded. That’s flyctl timing out while trying to provision or reach a Depot builder, which usually reflects Depot-side capacity or an outage in a particular region rather than anything wrong with your Dockerfile or your Stocky app. This has happened before: during a Depot builder outage, the recommended workaround was exactly --depot=false to fall back to the legacy builders, and there have been recurring reports of builds stalling on “waiting for depot builder” tied to regional capacity issues (DFW/IAD have both been culprits).
Do they have a status page so that I can tell when its working again?
Just +1’ing everyone here. Depot still appears to be timing out.
Same issue with my apps running in dfw. --depot=false worked for me. Thank you for the workaround post.
Curious why this isn’t showing on the status page yet…
Related:
There is a general impression amongst customers in this forum that not all updates on the status dashboard are automated. In other words, at least some of those updates are manually switched on and off.
The status page is only switched on/off manually when we handle incidents. That is not to say that during this incident we shouldn’t have put something on the status page much earlier than we actually did. There was a general impression that it might have affected only a subset of Depot builders on a host with issues before we were proven wrong. That’s a problem that we will address going forward.
You’ll probably also see a better write-up for this when the time comes for its Infra Log.