build.sh runs npm run build on macOS, so only the host's sharp binary
(darwin-arm64) got traced into the standalone output. The container
runs node:20-alpine (Linux, musl libc), which cannot load that binary
- the server crashed at runtime, causing a 502 even though the docker
build itself succeeded.
npm pack can fetch another platform's prebuilt sharp/libvips tarballs
without an install-time OS check, so build.sh now pulls the
linux-musl x64 and arm64 builds directly into build/node_modules and
drops the now-unused host binary.
The .gitignore fix in 4b8277a was reverted by 0d243fc, which re-tracked
a root-level .next/ (258MB, 2521 files) that this repo never needed —
the Dockerfile only consumes build/ (the rsynced standalone output from
build.sh). With no .dockerignore, that dead weight plus .git (bloated
to 725MB from repeated .next churn) was shipped into every Docker build
context on Dokploy, causing build failures/timeouts that surfaced as a
502 after deploy.
.gitignore's ".next/" rule (no leading slash) matched at any depth, so
build/.next was silently excluded from every commit even though build.sh
populates it. The Docker image was built without the compiled server/static
output, so server.js had nothing to serve. Anchor the rule to the repo root
and commit the compiled output that Dokploy actually needs.
Dokploy domains were configured to route to internal port 80, but the
Node standalone server listened on 3000, causing Bad Gateway. Align
the container's PORT/EXPOSE with Dokploy's routing instead.
The standalone build runs on macOS and bundles darwin-arm64 native
sharp binaries. These crash immediately on the Alpine Linux container,
causing the Node process to exit and Dokploy's reverse proxy to return
a 502 Bad Gateway.
This adds a RUN step to remove the macOS binaries and install the
correct @img/sharp-linuxmusl-x64 package at build time.
