Issue with deploying - Not enough space

JavaScript
,
1

Subject:

Fly.io: “Not enough space to unpack image, possibly exceeds maximum of 8GB uncompressed” — but my exported image is ~3.4 GB

Issue Summary:

I’m unable to deploy my Next.js app to Fly.io. Every time I deploy, I get the following error, even though my local image is well under the 8 GB limit:

[info]Pulling container image registry.fly.io/abstracta-v2:deployment-...
[error]Not enough space to unpack image, possibly exceeds maximum of 8GB uncompressed

What I’ve Done / Observed:

  • Local Docker build and export:
docker run -it --rm abstracta-v2 du -h -d 2 /
# (output)
3.2G	/
2.6G	/app
1.9G	/app/node_modules
683.0M	/app/.next
559.0M	/usr

mkdir /tmp/abstracta-v2-fs
docker export $(docker create abstracta-v2:latest) | tar -C /tmp/abstracta-v2-fs -xf -
dua /tmp/abstracta-v2-fs
# (output)
3.36 GB total
  • Deployed minimal/Hello World Docker images with no issues
  • Destroyed and recreated app, machines, and Fly caches
  • Pruned all local/remote Docker cache and images
  • Deployed both with local and Fly cloud builds
  • No large Fly.io volumes, mounts, or custom disk config
  • No errors in local builds, no excessive files in the image

Relevant Logs from Fly.io:

2025-05-16T23:51:59Z runner[d899237f6de408] iad [error]Not enough space to unpack image, possibly exceeds maximum of 8GB uncompressed
2025-05-16T23:53:40Z runner[3d8d453da33358] iad [error]Not enough space to unpack image, possibly exceeds maximum of 8GB uncompressed

--> Build Summary:  (​)
--> Building image done
image: registry.fly.io/abstracta-v2:deployment-01J...
image size: 3.7 GB

Questions:

  • Why does Fly.io think my image is over 8 GB when du/dua/docker export all show it’s well under?
  • Is there a way to force Fly.io to clear any backend image/cache/registry data that might be stale or corrupted?
  • Are there known quirks with image size calculations on Fly.io, or possible causes I’m missing?

Any advice on getting past this error or on additional debugging steps would be much appreciated. Thanks!

1 Like
2

Thanks for all the details… (@halfer and I should maybe award a weekly prize for the most in-depth and thorough thread opener, :thought_balloon:.)

The main state that could get wedged is on the physical host machine, from what I’ve heard, so deploying to a completely different region should shake you free of that.

In contrast, registry metadata is partly per-app, and partly per-organization. (You will definitely see sharing of layers between different apps, for example.)

Personally, I would try an old-fashioned bisection search here. Cut your dependencies, static files, etc., in half, then try redeploying.

If that also fails in the same place, then try cutting in half again.

Alternatively, if you’re a big spender, then you could try debugging on one of the the GPU Machines. Those have far higher RootFS limits (due to people wanting to put entire LLMs there).

The image sizes are definitely quirky, with none of the different ways of assessing them agreeing exactly, in my experience. I’ve never known them to be this far off, though.

In terms of other causes… I think the main thing that might be getting overlooked is simply the “possibly” in “possibly exceeds maximum”. This is a complicated LVM-ish/device-mapper setup under the hood, last I heard, and I’m pretty sure that the wording in this error message was deliberately chosen to indicate that there really are other things that can go wrong at this point, :dragon:.

For example, a fellow user mentioned in a blog post yesterday that they had bumped up against a limit on the number of layers (rather than the GB size). And in the past, others have reported having difficulty with a single layer being large (even though the total overall was OK).

Anyway, hope this helps a little!

1 Like
5

@mayailurus Thank you for the comments and suggestion. While I had deleted the app from fly completely, I redeployed using the same name and region.

I used your suggestion and selected a new region and app name. Changing nothing else, the app deployed and now works without a problem. Something must have gotten stuck in the old deployment pipeline, so, I wonder if there is a cleanup job that needs to be improved.

I am back to working now, thank you!

P.S. I’ll take a prize, can you award me some internet points for doing my homework? :laughing:

1 Like
6

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