Docker image: about 570 MB to about 110 MB?

[LudaThomas]

The ready-made image ghcr.io/henmedia/layerling:1.147.0 is about 570 MB compressed per platform (amd64 569.7 MB, arm64 566.5 MB). On a NAS or a slow connection that makes every update a long pull, so I looked at where the size comes from, and I have a branch that brings it to about 110 MB. Before opening a pull request I'd like to know whether you'd want it, and in what form.

Where the size comes from

From the layers of 1.147.0 (amd64, compressed):

Layer	Size	What's in it
COPY .next	320 MB	294 MB of it is .next/cache/webpack, the build cache, which the server never reads
npm ci --omit=dev	127 MB	all production dependencies, including the 143 MB (uncompressed) native Next compiler that next start doesn't use
Node on Debian base	81 MB	node:24-bookworm-slim with npm and yarn
public	42 MB	guides, fonts, OCCT kernel: real content

What the branch does

Branch: https://github.com/LudaThomas/layerling/tree/slim-docker-image (one commit: docker/Dockerfile and apps/web/next.config.ts)

• Standalone output for Docker only. output: "standalone" is set only when the Dockerfile sets LAYERLING_STANDALONE=true, so npm start and the static export behave as before. The image then ships only the server files Next traced, plus .next/static and public, with no build cache.
• A few files the tracer picks up but the server never needs: sharp (the image optimizer is off in next.config.ts), typescript, apps/web/src, and the bundler's copy of the CAD kernel wasm under _next/static/media. Every loader asks for /occt/<version>/, and generate-service-worker.mjs already skips that copy.
• Alpine runtime. The final stage is alpine:3.24 with a stripped Node binary from node:24-alpine3.24, with no npm, yarn or Debian. It still has a shell, so docker exec, NAS consoles and the printenv checks in the guides keep working.
• Nothing changes for existing installs. It still runs as 999:999 (Alpine's ping group is removed to free that id), and thumbnails still land in /app/.codex/project-thumbnails, where the documented volume is mounted. The standalone server changes into apps/web, so a link from apps/web/.codex leads back there.

Result: about 111 MB compressed (arm64) and 301 MB on disk.

Tested on arm64:

• the start page, the editor, the OCCT and manifold wasm, and the guide pages all load, with no console errors or failed requests;
• thumbnails save into an existing volume;
• the shared-projects folder is detected;
• docker stop exits cleanly.

amd64 and arm64 built and published from my fork (https://github.com/LudaThomas/layerling/actions/runs/42836119181), 113.5 MB compressed on both. Tested on arm64 (Apple Silicon) and amd64 (Intel Mac). Try it with docker pull ghcr.io/ludathomas/layerling:1.156.3-slim.

Trade-offs to be aware of

• The removal list is kept by hand. If a future Next version starts loading one of the removed packages at runtime, it fails at runtime, not at build time.
• Build and runtime use different Node builds. The app is built on Debian (glibc) and runs on Alpine (musl). Nothing at runtime uses a native module, but it is a difference.
• The image no longer runs next start. It runs node apps/web/server.js (still production mode), so the README line saying "The image runs next start" would need a small wording change.

Smaller options

If the full change is more than you want:

• Remove only the build cache. Add && rm -rf apps/web/.next/cache to the build step. That's one line with no other behaviour change, and should bring it to roughly 275 MB (estimated from the layers, not built).
• Standalone, but keep the Debian base. Avoids the musl difference. I haven't measured this size.

Would you take a pull request for this, and which version would you prefer?

[henmedia]

@LudaThomas Thanks for digging into this, the numbers match what I see in the Dockerfile: the whole .next folder goes into the image, build cache included. Yes, please open a pull request with the full version (standalone, the removal list and Alpine). 570 MB down to about 110 MB is a big difference for NAS users, and your tests cover what matters.

One wish, because the removal list is kept by hand: could the Docker workflow start the freshly built image and fetch the start page and the OCCT wasm before it tags latest? Then a future Next version that needs one of the removed packages fails in the workflow instead of on someone's NAS. Please also change the README line about next start in the same pull request.