Hotfix 0.52.2 — fix Sharp/glibc image-optimizer 500s on the Chainguard runtime#425
Merged
Conversation
…time The 0.52.1 .next/cache fix let the Next.js image optimizer finally run, which unmasked a latent Sharp failure: Dockerfile.app built on node:24-alpine (musl) and stripped Sharp's glibc binaries, but the runtime image cgr.dev/chainguard/node is glibc (Wolfi). Only @img/sharp-linuxmusl-x64 shipped into a glibc runtime → "Could not load the sharp module using the linux-x64 runtime" → /_next/image 500s on every avatar/icon (502 at the edge). Build on node:24 (Debian, glibc) and drop the musl-only strip so the glibc Sharp binary (@img/sharp-linux-x64) is installed, traced into standalone, and loads at runtime. Verified on a real linux/amd64 build: @img includes sharp-linux-x64, require('sharp') succeeds, and sharp encodes a WebP. Prisma unaffected (uses the @prisma/adapter-pg JS driver, not a native engine). Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Problem (production incident, follows v0.52.1)
After v0.52.1 deployed, every optimized image (
/_next/image— avatars, icons, background) returned 500 at the origin (502 through nginx/Cloudflare). Server logs:Root cause: a latent bug unmasked by the 0.52.1
.next/cachepermission fix. Previously the optimizer died atmkdir('.next/cache')(EACCES) before ever loading Sharp. Now that the cache is writable, it reaches Sharp — and fails, becauseDockerfile.appbuilt onnode:24-alpine(musl) and stripped Sharp's glibc binaries, while the runtime imagecgr.dev/chainguard/nodeis glibc (Wolfi). So only@img/sharp-linuxmusl-x64shipped into a glibc runtime.Diagnosis on the live container:
require('sharp')→Could not load the "sharp" module using the linux-x64 runtime@imghad onlysharp-linuxmusl-x64;process.report … glibcVersionRuntime: 2.43(glibc runtime)(Prisma was unaffected because it uses the
@prisma/adapter-pgJS driver — no native engine — which is why the DB worked but images didn't.)Fix
Build on a glibc base (
node:24Debian) instead ofnode:24-alpine, and drop the musl-only Sharp strip. Sharp's glibc binary (@img/sharp-linux-x64) is then installed, traced into the standalone output, and loads on the glibc Chainguard runtime.Verification (real
linux/amd64image, matching production)@imgcontentssharp-linux-x64(glibc) presentrequire('sharp')sharp({create…}).webp().toBuffer()succeeds(An initial arm64 local build passed too but tested the wrong arch — re-verified on amd64 to match prod.)
Deploy after tagging (
v0.52.2)Bump the server
docker-compose.ymlimages tov0.52.2(app + migrate),docker compose pull && up -d. Also finally swap thecurlhealthcheck for the node-based probe — Chainguard has no curl, so the container showsunhealthy(harmless to serving, but wrong).🤖 Generated with Claude Code