[error] Not enough space to unpack image, possibly exceeds maximum of 2GB uncompressed

Hi everyone. I’m trying to deploy a docker container app. Everything goes fine until the release stage, then it throws an error:
timeout reached waiting for machine to started failed to wait for VM 9080e19dfd7587 in started state: Get “https://api.machines.dev/v1/apps/drift-backend/machines/9080e19dfd7587/wait?nstance_id=01H03SK8AC1E57XX3WNKPBK49K&state=started&timeout=60”: net/http: request canceled

So I opened the log at the dashboard and it gives this error description:
sea [error] Not enough space to unpack image, possibly exceeds maximum of 2GB uncompressed

I’m not sure what to do now. I was thinking of increasing the timeout variable, but if there’s a limit of 2GB I guess it wouldn’t work anyway. My image is almost 10GB, but I was able to push to the registry, so how can I get this released?

Hi @rleitaopb. Unfortunately, I think you are right; increasing the timeout won’t help. There is currently a 2GB limit for the image size.

Would you mind sharing a bit more about your use case? (That is, why is your image so big?) This could help someone advise about potential workarounds, and also help us at fly.io decide how to prioritize new features in the future.

1 Like

Hi @darla, thanks for your response.
The image is big because it’s a Django app to manipulate audio files using deep learning Python libraries, like Tensorflow and Pytorch. It has lots of dependencies, so the app itself is 3Gb and when I create the Docker image it gets over 6Gb.

I guess I have 2 options:

  • Try to start with just a few simple functionalities and minimum requirements.
  • Migrate to another cloud server that is able to host bigger docker images.

Hi @rleitaopb! Thanks for the additional context. This is exactly one of the use cases we’ve discussed internally, so it is on the radar (but definitely no guarantee about if/when it will be solved).

I’ll suggest a third option that could work: you could put your libraries on a volume, and then update your PYTHONPATH to include the directory on the volume where the libraries are stored.

Now - this is a big hassle, and has some significant down sides. You very well may be better off migrating to another cloud provider. But it’s an idea you could experiment with, if you are so inclined. :slightly_smiling_face:


Hi @darla, this is a quite interesting suggestion. What are the possible downsides?

The main issue I can think about off the top of my head is that it complicates deploys (at least, when you need to update libraries). I haven’t actually done it, though, so you definitely may find some other issues!

This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.