I’m working from my remote office and experiencing a crazy slow connection when deploying to fly. I’m deploying to YYZ, but i noticed when i go to https://debug.fly.dev/ it says my region is “lga” or “arn” most of the time.
I’m on starlink when here, so I’m assuming despite being north of Toronto, I’m getting bounced to a different ground location. I had assumed it would still be pretty fast and fly must peer each of its datacentres, but I’m getting something like 100kbps at most…this seems extraordinary slow, making my 1.6gb image basically impossible to deploy.
Has anyone experienced this? Are there any work arounds other than simply driving back to the city and working from there?
Hey @andrewmcgrath! You weren’t alone in being sent to Stockholm today. Our team asked for a routing fix upstream. It’s looking good from my end now (I was affected as well); how about you?
I’m getting routed to LGA right now, that probably makes the most sense given starlink is probably sending me to a Quebec ground station. Having said that, I’m getting maybe 150kbps right now doing a deploy, pretty brutal still.
I implemented a work around by switching to a git actions hook that deploys from github, this works a lot faster (and well, actually just works) but i’d like to be able to do this locally for non-production environments.
I got a terrible connection myself and can’t even upload the 5MB docker context to start the remote build before timing out. I’ve resorted to deploying off a VPS, but is there a way to extend the upload timeout and ensure that the deploy is not interrupted? My understanding is that almost everything is happening client-side now, so a bad connection could be problematic?