Trim ~95MB of Prisma Studio from the runtime image - #9
Merged
Conversation
The migrator stage pulled in @prisma/studio-core and its UI stack (effect, @electric-sql, react-dom, elkjs) — about 95MB that `migrate deploy` never loads. Deleting it does not work: the CLI eagerly requires several @prisma/studio-core subpaths and dies with 'Cannot find module'. An npm override pointing at a stub with a wildcard exports map satisfies every subpath, and --install-links copies the stub into node_modules so it survives the COPY into the runner stage. Image drops from 685MB to 591MB. Pull and extract was ~120s of template's 202s deploy, and the old container is stopped before it starts, so this shortens the outage window on every deploy. Verified against the full production stack: all 4 migrations applied, the container exited 0, the app came up healthy and served the VAPID key. Co-Authored-By: Claude Opus 5 (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.
Why
Measured from template's last deploy (202s total):
~120s — 60% of the deploy — is pulling and extracting the image, and layer decompression is what pegged the server CPU. Coolify stops the old container at +18s but the new image isn't ready until +151s, so this is also the
no available serverwindow.ghcr.io/c4g/templatewas the largest of the three images at 716MB, and 252MB of it was the Prisma CLI tree added when migrations moved into the app image — mostly@prisma/studio-coreand its UI stack (effect,@electric-sql,react-dom,elkjs), none of whichmigrate deployloads.What
Deleting the package does not work — the CLI eagerly requires several
@prisma/studio-coresubpaths:So the migrator stage now installs it with an npm
overridepointing at a stub whoseexportsmap wildcards every subpath, and--install-linksso the stub is copied rather than symlinked (a symlink would dangle oncenode_modulesis COPYed into the runner stage).Image: 685MB → 591MB locally (the migrator tree itself goes 252MB → 156MB).
Verified
Built and ran the full production stack against the trimmed image:
GET /api/notifications/subscribe→{"publicKey":"trimkey"}— runtime env still read correctlyThe publish workflow's smoke test exercises this same path against the published image, so if a future Prisma upgrade changes which subpaths the CLI requires, it fails in CI before anything deploys rather than breaking a deployment.
Related change (not in this PR)
Template's Coolify
docker_compose_custom_build_commandwas changed from... buildto... pull. That phase runs at +12.9s, before "Removing old containers" at +18.4s, so the image is pulled while the old container is still serving. Together these should cut the outage from ~2.5 minutes to seconds. Merging this PR triggers a deploy that will exercise it.🤖 Generated with Claude Code