Skip to content

fix(docker): fetch arm64 prisma schema-engine for non_root image - #118

Merged
moicalcob merged 1 commit into
carto/mainfrom
fix/arm64-prisma-schema-engine
Jun 22, 2026
Merged

fix(docker): fetch arm64 prisma schema-engine for non_root image#118
moicalcob merged 1 commit into
carto/mainfrom
fix/arm64-prisma-schema-engine

Conversation

@moicalcob

Copy link
Copy Markdown

Problem

The arm64 variant of litellm-non_root ships the arm64 query engine but no arm64 schema-engine — only schema-engine-debian-openssl-3.0.x (amd64). As a result, on Apple-Silicon / arm64 hosts prisma migrate deploy fails at boot:

Error: Could not find schema-engine binary. Searched … schema-engine-linux-arm64-openssl-3.0.x

litellm boots (the arm64 query engine connects, so queries run) but the DB is never migrated — every LiteLLM_* table is missing, and any flow that touches them 401/500s. amd64 (CI, prod) is unaffected, which is why this only bites local arm64 dev.

Root cause

On the Wolfi base, prisma-client-py's platform detection is arch-blind:

# prisma/binaries/platform.py
def binary_platform() -> str:
    distro = linux_distro()           # Wolfi isn't alpine/rhel -> "debian"
    ...
    return f'{distro}-openssl-{ssl}'  # -> "debian-openssl-3.0.x"  (no arm64/amd64!)

So the build resolves the schema-engine platform to debian-openssl-3.0.x (the amd64 binary) on both arches. The query engine escapes this only because schema.prisma's binaryTargets includes "native", which resolves the true arch.

Fix

Name the arm64 target explicitly in PRISMA_CLI_BINARY_TARGETS (both build + runtime stages) so the build-time online fetch pulls the arm64 schema-engine alongside the debian one:

-    PRISMA_CLI_BINARY_TARGETS="debian-openssl-3.0.x" \
+    PRISMA_CLI_BINARY_TARGETS="debian-openssl-3.0.x,linux-arm64-openssl-3.0.x" \

amd64 is unchanged (debian engine still fetched); the extra arm64 engine on the amd64 image is a few MB of harmless dead weight (could be made arch-aware via ARG TARGETARCH if preferred — happy to switch).

Verification

Built --target builder --platform linux/arm64 with the change and inspected the image:

/app/.cache/.../@prisma/engines/schema-engine-debian-openssl-3.0.x        # amd64 (kept)
/app/.cache/.../@prisma/engines/schema-engine-linux-arm64-openssl-3.0.x   # NEW, arm64
$ schema-engine-linux-arm64-openssl-3.0.x --version
schema-engine-cli ac9d7041…    # execs natively on aarch64

With this, the arm64 image self-migrates on boot (USE_PRISMA_MIGRATE=true) — no amd64 emulation needed for local dev.

🤖 Generated with Claude Code

On the Wolfi base, prisma-client-py's platform detection is arch-blind
(binary_platform() -> "debian-openssl-3.0.x" with no CPU arch), so the
build only ever provisioned the amd64 schema-engine. The arm64 image
therefore shipped the arm64 *query* engine (via schema.prisma's "native"
target) but NO arm64 *schema* engine — so `prisma migrate deploy` fails at
boot on arm64 ("Could not find schema-engine binary"), leaving the DB
unmigrated. amd64 (CI, prod) is unaffected.

Name linux-arm64-openssl-3.0.x explicitly in PRISMA_CLI_BINARY_TARGETS so
the build-time (online) fetch pulls the arm64 schema-engine alongside the
debian one. Verified by building --target builder --platform linux/arm64:
schema-engine-linux-arm64-openssl-3.0.x now lands in @prisma/engines and
execs natively (`schema-engine-cli --version` runs on aarch64).

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
@moicalcob moicalcob assigned mateo-di and moicalcob and unassigned mateo-di Jun 22, 2026
@moicalcob
moicalcob requested a review from mateo-di June 22, 2026 17:02
@moicalcob
moicalcob merged commit aec2325 into carto/main Jun 22, 2026
10 checks passed
Cartofante pushed a commit that referenced this pull request Jul 14, 2026
Re-add PRISMA_CLI_BINARY_TARGETS to Dockerfile.non_root builder stage
to fetch the arm64 schema-engine binary alongside the amd64 one. Without
this, prisma migrate deploy fails on Apple Silicon / arm64 hosts because
only the amd64 schema-engine is available

This restores CARTO PR #118 functionality that was incorrectly dropped
during the upstream sync conflict resolution
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants