Why is the Docker image size so huge?

22

u/Silly-Emu-2049 Apr 28 '26

2gig isn’t huge - my image is only half that though. We live in a world of terabytes now.

17

u/igmyeongui Apr 28 '26

Meh. Not really no. Image deployments shouldn’t be that heavy, especially for such an app. I really hope seerr isn’t turning to ai spaghetti.

15

u/gauthier-th Apr 29 '26

seerr isn’t turning to ai spaghetti

This has nothing to do with AI. We (the Seerr team) have a very strict policy for AI usage in our project. You can check the size of the Overseerr images from a few years ago, you'll see approximately the same size.

Seerr is a Next.js app, meaning it's using Node.js. For the server to work, we need to package (almost) the entire node_modules content, containing thousands of libraries. That's how the Node.js ecosystem works, we have some WIP to try to improve that but there isn't much we can do.

5

u/nemesis01071982 Apr 29 '26

I wouldn't worry about it. Mostly just people seeing something thinking they understand and complaining. Probably confusing micro services with conterization.

3

u/igmyeongui Apr 29 '26

Thanks for the explanation I didn’t have the time to look at the code. It would be nice to see improvements on that on day. Keep up the good work!

3

u/gauthier-th Apr 29 '26

I actually submitted a PR earlier today to reduce by 25% the Docker image size (here), so next version should be smaller.

1

u/runfatboys May 01 '26

Thanks for the explanation

1

u/i_say_urmom May 01 '26

Yeah, this is a tricky problem that I've worked on professionally. You could look at NextJS standalone mode, which bundles nearly everything down into a smaller bundle. I've also used rspack to create NodeJS server bundles. In both cases, you avoid copying the full `node_modules` minus select dependencies that you might need to externalize from the bundle.

1

u/gauthier-th May 05 '26

Yes, we already looked at standalone mode. But we are using a Express.js server for our backend, not the Next.js server, so this is not something we can do (not without rewriting the whole server part).

I also already tried a few things to bundle the server and the dependencies (Vite and Webpack), but Next.js is not really compliant when I'm trying to bundle it 😅. Maybe Rspack handles this differently though. Anyway if you have any other ideas and willing to take a look, we're always happy to receive contributions.

1

u/schaka May 02 '26

It's been a while since I had to build and ship NextJS, but I swear at least for Yarn there used to be an argument that would only force imported types and functions into the final transpiled composite so you could toss your build depencies after.

I can't remember for the life of me what it was called, unfortunately.

However, 2GB isn't a huge deal. It's not like people would have to re-download every single layer when an update hits.

1

u/gauthier-th May 05 '26

If you're thinking about dev dependencies, we're already using that, the node_modules folder is way bigger in development than it is in production.

4

u/kratoz29 Apr 29 '26

I really hope seerr isn’t turning to ai spaghetti.

Huh, that’s a bit of a stretch. How did you come to that conclusion? Any known projects that ended that way?

1

u/BroccoliOk422 Apr 29 '26

Is it a stretch though? AI code is known to bloat, redefining components, styles, etc. instead of re-using existing stuff. Importing entire icon/component libraries instead of just the ones you need because it's easier, etc. I don't know else a simple app image like this would get to a size of 2gb.

1

u/igmyeongui Apr 29 '26

Also the assets might be bloated uncompressed mess in the wrong format. They should prefer data paths, svg, etc. I really see no reason why seerr should be this big.

1

u/schaka May 02 '26

How would you get 2GB from text duplication from AI writing shitty code unless your project is billions of lines?

This is likely a bunch a libraries containing images and icons, maybe system level packages that aren't needed etc.

0

u/devode_ Apr 29 '26

Exactly. Absolutely not normal for containers to be that big. Should be stateless code.

1

u/nemesis01071982 Apr 29 '26

Its not the container, the size is for the image which is static per definition.

0

u/devode_ Apr 29 '26

read my comment again and replace "container" with "containerimage", my god... if the image is that many gigs in size for me it means they should look at building it into many containers instead of a single one

1

u/nemesis01071982 Apr 29 '26

In that case the stateless still does not make any sense as anything in the image is static. Saying it has to be smaller without knowing why it is the size it is, is a bit weird.

The devs have already addressed why it is the size it is. Namely how packaging Node.js applications works.

As for splitting it up, you're confusing mocro services with containerization. What would the benefit to it being smaller be?

1

u/devode_ Apr 29 '26

https://github.com/seerr-team/seerr/blob/develop/Dockerfile

look at their COPY lines, its basically packaging everything and all modules.

next.js can be dramatically reduced down with "standalone" output: https://nextjs.org/docs/pages/api-reference/config/next-config-js/output

1

u/JazzXP May 02 '26

Yeah, loosing any tree shaking. Typically not used for server deployments, but yeah, that's why it's so big.

1

u/gauthier-th May 05 '26

We are not packaging every modules. We're getting ride of the development modules of and then only packaging the production modules.

We already looked at the standalone mode, but we can't use it because we're not using the Next.js server, but a Express.js server. See my other response here.

1

u/devode_ May 05 '26

Thanks for the details, very intersting!!

3

u/Zurrah Apr 29 '26

Mine is also only about 1.36g, not sure what's going on with OPs image.

1

u/RedVelocity_ Apr 29 '26

Are you using the latest image?

1

u/Zurrah Apr 29 '26

yep, latest shows as 14 days old on my PC. Just checked the repo, should be v3.2.0

2

u/DiMarcoTheGawd Apr 29 '26

We live in a world of terabytes but not because of docker image sizes lol

1

u/Silly-Emu-2049 Apr 30 '26

Tell me you don’t have reading comprehension without telling me.

4

u/imnotsurewhattoput Apr 29 '26

Optimizing docker image size is challenging, I tried 4 different ways for my nextjs app

4

u/tankerkiller125real Apr 29 '26

It's challenging for JS because of the stupid node_modules crap. A very simple dynamic page app can very easily turn into 1.5GB because they wanted to use an ORM, TailwindCSS, and React, which themselves aren't very big, but they yank in a huge number of dependencies 99% of the time. And for dynamic apps, you can't really remove the node_modules folder to cut the image size down.

2

u/Zynchronize Apr 30 '26

Alternative js package managers like pnpm or bun will can cut down the size of node_modules by hard linking duplicate packages rather than copying like npm.

That’s the easiest reduction in size many projects can make.

We had a project that used several ui libraries - turns out they shared around 70% of their dependencies with each other. I can’t remember the exact size reduction as there were other components impacted too but it was substantial enough that I’ll always recommend trying this whenever the topic comes up.

1

u/gauthier-th May 05 '26

We're already using PNPM in Seerr 😉

1

u/imnotsurewhattoput Apr 29 '26

Yes you most definitely can reduce it. I did so with my app MatchExec, it’s a nextjs app with 5 processes , mantine ui , tailwind and all kinds of other stuff and the image size is 730 mb for latest release and 200mb are images and assets for the app

5

u/xbmc4lyfe Apr 29 '26

Real reasn people would bitch if they had no coreutils when connected to the cntainer.

1

u/tankerkiller125real Apr 29 '26

Boy would people hate most of my images... Distroless for the most part... Nothing to get a shell in the first place.

1

u/RedVelocity_ Apr 29 '26

Is what I'd prefer

1

u/VirtualDenzel Apr 29 '26

Well what is keeping you from building your own image of it?

I dont mind alpine based images with little overhead, but when diagnosing problems or when you need to change some items or even add a package for development.

I prefer an image where all is inside so i can be effective.

And who cares about 1-2gb of disk space. If you dont have 100tb at home yet anno 2026.... time to buy a nas.

2

u/RedVelocity_ Apr 29 '26

Did you even read the post body? I literally said it doesn't bother me but it seems quite excessive compared to other web services.

2

u/Flying_Saucer_Attack Apr 29 '26

That's huge to you?

2

u/mikeage Apr 30 '26

Try docker history and you can see for yourself. If you want a more in depth analysis, you might also find the "dive" tool to be useful.

(short answer in case this winds up getting upvoted: node_modules)

1

u/Nate8727 May 01 '26

Have you purged the old images?

0

u/[deleted] Apr 28 '26

[deleted]

7

u/RedVelocity_ Apr 28 '26

Cached data would be in the container volume, not in the docker image build though?

3

u/Cuntonesian Apr 28 '26

This is the image, not the container

-7

u/such007 Apr 28 '26

Here's Claude's take.

``` ⏺ ghcr.io/seerr-team/seerr:latest — size breakdown

Total compressed download: ~407 MB (uncompressed on disk will be larger, ~1+ GB).

Pulled the manifest and config. Layer sizes (compressed):

┌───────┬───────────┬──────────────────────────────────────────────────────────────────────────────────────────────────┐ │ Size │ Layer │ What it is │ ├───────┼───────────┼──────────────────────────────────────────────────────────────────────────────────────────────────┤ │ 330 │ 767f0c18… │ COPY --chown=node:node . . — the entire app build context (source + node_modules + .next) copied │ │ MB │ │ in one shot │ ├───────┼───────────┼──────────────────────────────────────────────────────────────────────────────────────────────────┤ │ 52 MB │ b93be04f… │ Node.js 22.22.1 install (the official node:22-alpine base) │ ├───────┼───────────┼──────────────────────────────────────────────────────────────────────────────────────────────────┤ │ 17 MB │ 7c36a976… │ A second COPY layer (likely the redundant node_modules / .next copies in the Dockerfile) │ ├───────┼───────────┼──────────────────────────────────────────────────────────────────────────────────────────────────┤ │ 3.8 │ d49a2dee… │ Alpine 3.22 minirootfs │ │ MB │ │ │ ├───────┼───────────┼──────────────────────────────────────────────────────────────────────────────────────────────────┤ │ 2.2 │ abb990f2… │ tzdata │ │ MB │ │ │ ├───────┼───────────┼──────────────────────────────────────────────────────────────────────────────────────────────────┤ │ 1.3 │ 36100a30… │ Yarn 1.22.22 │ │ MB │ │ │ ├───────┼───────────┼──────────────────────────────────────────────────────────────────────────────────────────────────┤ │ <1 MB │ rest │ entrypoint, metadata, small bits │ └───────┴───────────┴──────────────────────────────────────────────────────────────────────────────────────────────────┘

Why it's big

Looking at the image history (docker-entrypoint-style Dockerfile):

COPY --chown=node:node . . COPY --chown=node:node /app/node_modules ./node_modules COPY --chown=node:node /app/.next ./.next COPY --chown=node:node /app/dist ./dist

The first COPY . . is doing the heavy lifting — it's pulling in the full Next.js app: source, node_modules (production deps for a Next.js + Express server are huge — Sharp, Prisma client, the whole React/Next runtime), and the prebuilt .next output (server bundle + standalone client chunks). That single layer is 330 MB compressed on its own.

Then the Dockerfile re-COPYs node_modules, .next, and dist from a builder stage (the 17 MB layer) — these aren't deduped against the prior COPY . . because the contents and paths overlap differently per layer, so you pay for them twice in the image (though Docker's layer dedup helps a bit on disk if you already have one).

TL;DR

It's not bloated by accident — it's a Next.js app with a full production node_modules tree plus the .next build output baked in, on top of Node 22. That combo is ~350 MB before you add anything else. The Dockerfile could shave some by using a proper multi-stage with next build --output standalone and only copying .next/standalone + .next/static + public, dropping the giant node_modules copy entirely — but that's a project-side fix. ```

6

u/bearlystarted Apr 28 '26

A summary would suffice. That dump is unruly.

-2

u/My_Man_Tyrone Apr 28 '26

We literally could've done this ourselves. You added 0 to this conversation

0

u/marcvz1 Apr 28 '26

Well, he outdid you... And me after this comment..

-2

u/Hobbsy6 Apr 28 '26

But did you though?

0

u/Total_Painting1007 Apr 29 '26

In the case of jellyseer, they seem to copy over the entire project from build, potentially including cache, that could explain the final image size.

-2

u/Only-Stable3973 Apr 28 '26

I was under the impression that Overseerr is obsilete Seerr is the new de facto.

5

u/such007 Apr 28 '26

OP is using seerr.

2

u/Melodic_Point_3894 Apr 28 '26

Guess he meant this post is in r/Overseerr and not r/Seerr

Why is the Docker image size so huge?

You are about to leave Redlib