Fly.io Bug? Targeting AMS but Getting LHR Capacity Errors After FRA Attempt

[yaniv]

hello all,

i have tried to fly launch to region fra but I got a status error with a recommendation to deploy it to Amsterdam since Frankfurt is already full then I delete it and try to launch it again this time to Amsterdam but I got the same enormous message but this time it say that I have tried to deploy it to London and I should deploy it to Amsterdam.

to conclude:

• The region-switching attempts (fra → ams).
• The unexpected lhr error despite targeting ams.

this is the msg:

Status

Service interruptions, incidents or issues affecting the apps in your organization

Incidents & Maintenance

Capacity issues in LHR region

1. Identified2025-03-14 13:55:09 UTCNew machine/volume creates in LHR regions are currently unavailable as there is no host capacity available. Any workloads currently running will continue to run; it is also still possible to update existing machines/volumes. Increasing fly scale count in LHR region is not possible. Blue-green deploys are also not possible at the moment, as well as deploys with release_command. We expect more capacity to become available in the coming weeks. For the time being, please choose a nearby region for new workloads, such as AMS (Amsterdam, Netherlands) or ARN (Stockholm, Sweden).

[lillian]

Can you copy-paste the fly launch command you’re running and the exact output?

[yaniv]

yes sure,

fly launch --name x-realestate-client --region ams --vm-size shared-cpu-1x --vm-memory 256 --no-deploy


flyctl --app x-realestate-client secrets set VITE_APP_API_ENDPOINT=https://x-realestate.fly.dev
# secrets set ....

fly deploy --app x-realestate-client 

the toml file

app = 'x-realestate-client'
primary_region = 'ams'

[build]
  dockerfile = 'docker/Dockerfile'

[http_service]
  internal_port = 3000
  force_https = true
  auto_stop_machines = 'stop'
  auto_start_machines = true
  min_machines_running = 0
  processes = ['app']

[[vm]]
  size = 'shared-cpu-1x'

the output

fly deploy --app x-realestate-client
==> Verifying app config
Validating D:\Code\real-estate-app\client\fly.toml
✓ Configuration is valid
--> Verified app config
==> Building image
Waiting for depot builder...
Waiting for depot builder...
Waiting for depot builder...
Waiting for depot builder...
Waiting for depot builder...
Waiting for depot builder...
Waiting for depot builder...
Waiting for depot builder...
Waiting for depot builder...
Waiting for depot builder...
Waiting for depot builder...

Waiting for depot builder...
🌎error reporting health: unavailable: read tcp 192.168.##.##:#####->44.###.##.###:443: wsarecv: A connection attempt failed because the connected party did not properly respond after a period of time, or established connection failed because connected host has failed to respond.error reporting health: unavailable: read tcp 192.168.##.##:#####->44.###.##.###:443: wsarecv: A connection attempt failed because the connected party did not properly respond after a period of time,Error: failed to fetch an image or build from source: error building: context deadline exceeded

i have change the IP numbers with # (192.168.##.##:#####->44.###.##.###:443)

 fly doctor
Testing authentication token... PASSED
Testing flyctl agent... PASSED
Testing local Docker instance... Nope
Pinging WireGuard gateway (give us a sec)... PASSED
Testing WireGuard DNS... PASSED
Testing WireGuard Flaps... PASSED

App specific checks for x-realestate-client:
Checking that app has ip addresses allocated... Nope
        No ip addresses assigned to this app. If the app is not intended to receive traffic, this is fine.
        Otherwise, it likely means that the services configuration is not correctly setup to receive http, tls, tcp, or udp traffic.
        https://fly.io/docs/reference/configuration/#the-services-sections
No public ipv4 or ipv6 ip addresses allocated to app x-realestate-client

Build checks for x-realestate-client:
Checking docker context size (this may take little bit)... PASSED (216 kB)
Checking for .dockerignore... PASSED

AI:
The context deadline exceeded error isn’t from my config or network—it’s likely Fly.io’s Depot builder failing to respond (possibly overloaded, as seen with lhr capacity issues). The wsarecv timeout (Windows-specific) hints at a transient builder connection drop.

[lillian]

The AI response is incorrect, this is not at all related to the capacity issues. It does seem like a Depot issue though, could you try deploying with --local-only or --depot=false ?