Official download method for Prisma 6.19.3 Linux ARM64 query engine

[xw564477242-cmyk]

We need the Prisma 6.19.3 query engine for an isolated test environment. Engine commit: c2990dca591cba766e3b7ef5d9e8a84796e47ab7. Platform: linux-arm64-openssl-3.0.x. File: libquery_engine.so.node.gz. The following URL returned HTTP 403: https://binaries.prisma.sh/all_commits/c2990dca591cba766e3b7ef5d9e8a84796e47ab7/linux-arm64-openssl-3.0.x/libquery_engine.so.node.gz . Please confirm the correct official download method and provide the corresponding SHA-256 verification information. We do not need assistance accessing our project or databases.

[keremoktener]

I checked the 6.19.3 version pin and downloader: your commit and URL match the source.

The documented install-time download method is to run this in a disposable directory on a connected staging machine:

PRISMA_CLI_BINARY_TARGETS=linux-arm64-openssl-3.0.x npm install --save-dev --save-exact prisma@6.19.3

With the default library engine, check for node_modules/@prisma/engines/libquery_engine-linux-arm64-openssl-3.0.x.so.node. Verify the actual file before transferring it: the postinstall handler catches download errors, so a successful npm exit alone doesn’t prove the engine was downloaded. This uses the same download service and won’t itself resolve the 403.

Prisma’s downloader verifies two sidecars in the same directory as your URL:

• libquery_engine.so.node.gz.sha256: hash of the compressed download
• libquery_engine.so.node.sha256: hash of the decompressed library

Compare each sidecar’s first hexadecimal field with the corresponding file’s SHA-256; retain the sidecars with the artifact. The archive and extracted library have different hashes. I haven’t retrieved their current contents, so I can’t provide verified hash values.

I’d keep checksum verification enabled and share the 403 response body and non-sensitive response headers, especially any CDN request ID. Those would give maintainers something concrete to investigate without needing project or database access.

[spokodev]

The URL in your post works from here. On 2026-10-10 at 14:34 UTC it returned 200 with 7,308,875 bytes, served through Cloudflare, and both checksum files next to it returned 200 as well:

https://binaries.prisma.sh/all_commits/c2990dca591cba766e3b7ef5d9e8a84796e47ab7/linux-arm64-openssl-3.0.x/libquery_engine.so.node.gz
https://binaries.prisma.sh/all_commits/c2990dca591cba766e3b7ef5d9e8a84796e47ab7/linux-arm64-openssl-3.0.x/libquery_engine.so.node.gz.sha256
https://binaries.prisma.sh/all_commits/c2990dca591cba766e3b7ef5d9e8a84796e47ab7/linux-arm64-openssl-3.0.x/libquery_engine.so.node.sha256

The commit is the one 6.19.3 pins: @prisma/engines@6.19.3 depends on @prisma/engines-version@7.1.1-3.c2990dca591cba766e3b7ef5d9e8a84796e47ab7.

SHA-256 from the two checksum files, which match what I downloaded:

f46c5c49fad7402fd3cec5bc7cd827e5872895729430aa0715b84a548b2a77ae  libquery_engine.so.node.gz
3de76598179b95c6910e28547ee3af9236d978cd3e0917b63a3b531f84bfb8d0  libquery_engine.so.node

The second one is the decompressed library, an ELF 64-bit ARM aarch64 shared object. To check both on your side:

gunzip -c libquery_engine.so.node.gz > libquery_engine.so.node
sha256sum libquery_engine.so.node.gz libquery_engine.so.node

Using the file without a download. Set PRISMA_QUERY_ENGINE_LIBRARY to the path of the decompressed file. The client reads that variable before looking anywhere else (resolveEnginePath.ts), and the engine download is skipped when it points to an existing file. I checked it with the 6.19.3 CLI and the darwin-arm64 build of the same engine: prisma -v printed resolved by PRISMA_QUERY_ENGINE_LIBRARY, and with an empty cache the CLI requested no query engine file. It did request the schema engine; if you run the CLI in that environment, PRISMA_SCHEMA_ENGINE_BINARY is the matching variable (env.ts).

Or a mirror you host. PRISMA_ENGINES_MIRROR replaces https://binaries.prisma.sh and keeps the rest of the path (utils.ts). Pointed at an empty local server, the CLI asked for /all_commits/c2990dca591cba766e3b7ef5d9e8a84796e47ab7/darwin-arm64/schema-engine.sha256 and schema-engine.gz.sha256, then stopped with Failed to fetch sha256 checksum. So the mirror needs the checksum files next to each archive, unless PRISMA_ENGINES_CHECKSUM_IGNORE_MISSING is set.

About the 403: every wrong path I tried on that host gives 404, not 403 (another commit, another platform, a directory, a misspelled file name), so a 403 isn't what it returns for a missing file. Since the same URL works from here, the block is more likely on the way from your network than on the file itself.