I’ve just had an issue where I was struggling to deploy, and tbh I’d put this down to some sort of issue with the builders. After eventually looking at what the deploy was actually doing, I noticed it was transferring ~1.3GB (slowly) … which was weird, as my repo is < 30MB in Github.
Turns out it was of course my fault, .a bunch of tool caches (Playwright browsers, .npm, .local, etc.) had quietly piled up inside the build context.
It wasn’t a .dockerignore bug — mine was being honored fine, it just didn’t have entries for those dirs because I had no idea they were there. Three extra lines and the transfer dropped from 1.3GB to a few MB. Deploys are fast again.
Nothing in flyctl flagged it. The slowness was the only symptom, and it’s very easy to misattribute that to the builders rather than to your own context being bloated.
Feature request: when the build context is unexpectedly large (say >100MB, or configurable), could flyctl warn and show the worst offenders? Something like:
Build context is 1.3 GB — this can slow deploys.
Largest paths: .cache/ (1.0 GB), .npm/ (300 MB)
Add these to .dockerignore if they shouldn’t be deployed.
BuildKit already knows the context size since it’s measuring it for the transfer anyway. Even just printing the total + top few paths would’ve saved me a lot of head-scratching. Bonus points for an optional --max-context-size that fails the deploy unless overridden, so it can be enforced in CI.
I’d argue this isn’t a Fly thing, it’s a Docker thing. If your CI environment has Docker in it, you can probably issue a command to work out the size of the build context, and then print your warning with a conditional.
I’d add also that this won’t happen in traditional CI, so I wonder if you’re just deploying from your local machine. In CI there is a fresh checkout on an empty VM, so cache accumulation isn’t possible.
Correct, I was deploying from my local machine, not something I have normally done – hence likely not having hit this before.
I don’t debate this wasn’t my error, I just figured it would be useful to have the warning? Ultimately this only really affects me, though presumably it puts some (minor) additional strain on Fly’s services.
Certainly it was frustrating, and I was blaming Fly before realising it was my mistake. Such a simple-to-implement thing pointing out when users are “holding it wrong” would be a small nudge towards said users having a slightly better customer experience?
I don’t work for Fly, but I’d say that if this feature would only cater for folks deploying from their laptops, it’s not the market they want to serve. The customers buying cloud will nearly all have CI workflows.
I should think you could get AI to write a shell script for you, before calling flyctl deploy; I don’t doubt it’d be useful.
I’ll be honest, part of the reason I’ve been deploying from my Mac is that the deploys have been fairly flaky for me and I’ve lost a bit of confidence, so I want them to run from local on this personal project so they’re not just eating up GitHub actions minutes etc. when there are issues.
I actually do have a shell script that wraps deploy to help with versioning etc., but I didn’t know this was an issue… so had never thought to check in that script. My point remains that this would be a little nice-to-have that would help point out issues people may be having without realising. Ultimately putting anything in that script was the wrong call, just simply fixing the .dockerignore was the right approach. I actually think putting anything in that script would be the wrong place to catch this, it should live in the tool itself.
I guess I also don’t agree that it would only help people on laptops. If you’d not separated out your deploy and ci steps, I believe that could potentially hit the same issue. Granted that would likely not be the best way to set up CI, but the whole point around this suggestion is a small improvement for developer experience to gently point out when people have, without realising, made choices that are having a negative impact.
this is definitely not true, and as robgough pointed out it’d also help anyone accidentally pushing way too much stuff into their docker image in CI.
I don’t think we’ll add this ourselves anytime soon but would be happy to review a PR https://github.com/superfly/flyctl
Build context is 1.3 GB — this can slow deploys.