binaryTargets equivalent with @prisma/engines?

[gcb]

How can I prime the filesystem with a specific platform engine files to prepare for deploy?

with binaryTargets I simply added them like binaryTargets = ["native", "debian-openssl-3.0.x"] to release to a debian host, for example.

The production host will not be able to download code on the fly.

[siaym]

To prime the filesystem with engine binaries for an offline or air-gapped production host, you have three primary approaches depending on whether you are using standard prisma generate, @prisma/engines programmatic downloading, or environment variables:

Approach 1: Recommended Pattern (binaryTargets in schema.prisma during Build Step)

binaryTargets is still the official way to pre-fetch engine binaries. You run this during your build/packaging step (in CI or your Docker builder stage where outbound internet access is available):

1. In your schema.prisma:

   generator client {
     provider      = "prisma-client-js"
     binaryTargets = ["native", "debian-openssl-3.0.x"]
   }

2. Run generation during the build phase:

   npx prisma generate

   This downloads the debian-openssl-3.0.x engine binaries directly into node_modules/.prisma/client/ (e.g., libquery_engine-debian-openssl-3.0.x.so.node).
3. Bundle node_modules/.prisma/client into your production deployment artifact (e.g. Docker production stage or deploy archive). The production host will run the pre-downloaded engine completely offline.

---

Approach 2: Programmatic Pre-download using @prisma/engines

If you are writing a custom build script with @prisma/engines directly, you can install @prisma/engines as a dev dependency and invoke its download utility in a pre-deploy Node.js script:

const { download } = require('@prisma/engines');
const path = require('path');

async function primeEngines() {
  await download({
    binaries: {
      'query-engine': path.join(__dirname, 'engines'),
      'schema-engine': path.join(__dirname, 'engines'),
    },
    binaryTargets: ['debian-openssl-3.0.x'],
    showProgress: true,
  });
  console.log('Engines downloaded successfully for debian-openssl-3.0.x');
}

primeEngines();

---

Approach 3: Pre-staging Engines via Environment Variables

If your engines are stored in a local artifact cache or mounted from a shared storage volume on the host, point Prisma directly to the file paths using environment variables:

# Point directly to your offline engine file:
export PRISMA_QUERY_ENGINE_LIBRARY="/app/engines/libquery_engine-debian-openssl-3.0.x.so.node"
export PRISMA_SCHEMA_ENGINE_BINARY="/app/engines/schema-engine-debian-openssl-3.0.x"

When these environment variables are set, Prisma Client bypasses runtime engine resolution and uses the specified local files directly without attempting any network requests.

[gcb]

Awesome answers all around. Thanks everyone!

I mostly asked because I did not see mentions of the binaryTargets parameter in the migration guide.

But wait, I misread above before... The recommended way is to keep "prisma-client-js"?!?

[sandeep-2607]

One thing to add: what you need depends on which generator you're on, because Prisma 7 changed this.

prisma-client-js (the v6-style generator): binaryTargets = ["native", "debian-openssl-3.0.x"] plus prisma generate at build time is still the way to go.

prisma-client (the Prisma 7 default): there's usually nothing platform-specific to prime for the client.

• In the Prisma 7 schema reference, the prisma-client generator has no binaryTargets or engineType field. Those are only documented for prisma-client-js.
• The v7 upgrade guide says prisma-client "uses the new Rust-free client" with a driver adapter (e.g. @prisma/adapter-pg). It lists PRISMA_QUERY_ENGINE_LIBRARY and PRISMA_QUERY_ENGINE_BINARY among the env vars removed in v7, so on v7 those won't help.

So on v7 you run prisma generate at build time and ship the generated output plus node_modules. Nothing gets downloaded on the host at runtime.

What may still need a native binary is the CLI side: the Schema Engine used by prisma migrate deploy. The @prisma/engines page says its postinstall downloads "the Query Engine and the Schema Engine". I'm not sure how much of that still applies in v7, so two safe options for an offline host:

1. Run prisma migrate deploy from CI (or any machine with network access) against the production DB, instead of on the host.
2. Or install dependencies in a build stage whose platform matches the host, and ship that node_modules:

FROM node:22-bookworm AS build   # Debian 12 -> debian-openssl-3.0.x
WORKDIR /app
COPY package*.json ./
RUN npm ci                       # postinstall fetches whatever the CLI needs for this platform
COPY . .
RUN npx prisma generate

If you can share your Prisma version and which generator provider you're using, I can narrow this down.

[gcb]

So on v7 you run prisma generate at build time and ship the generated output plus node_modules. Nothing gets downloaded on the host at runtime.

So, (excluding the CLI doubt) there is no binary module whatsoever now? The doc always mention rust-free, and I assumed it was a combination of C++ and JS :) is it 100% JS now?

Our setup is a little weird. Most FE hosts receive the node_modules+generated_code and will fail if anything is missing... and the DB host runs the migrations, but it is allowed to fetch via something similar to npm ci all the dev dependencies (not included in the release package) to run the migration scripts. So, it might just work out?

[gcb]

@prisma/adapter-pg@7.10.1
@prisma/client@7.10.1

datasource db {
  provider = "postgresql"
}
generator client {
  provider     = "prisma-client"
  output       = "../lib/generated_prisma"
  moduleFormat = "esm"
}

[gcb]

Also, if there's only JS and it is covered by prisma generate, can I block prisma post install scripts since i believe they only downloaded the engines?

[sandeep-2607]

Good Questions @gcb

With prisma client on 7.x there’s no native binary on the client side anymore. Prismas Rust-free notes say you do not need to worry about query engines or binaryTargets now, and the old engine file should not appear in your generated folder, so thats an easy way to check. I am not 100% sure if the new query compiler is plain JS or uses Wasm internally, but it is not platform-specific, so your FE hosts only need the generated client plus @prisma/client and @prisma/adapter-pg.

Your Database host plan should work too. The schema engine used by prisma migrate deploy is still a native binary, and its downloaded from Prismas binaries server during install, not from the npm registry. So if that host can only reach npm, use the PRISMA_CLI_BINARY_TARGETS=debian-openssl-3.0.x npm ci tip from the other reply on a machine with internet and ship that.

For blocking postinstall scripts, I’d just test it: npm ci --ignore-scripts && npx prisma generate, then start the app once. I’d keep scripts enabled on the Database host, since migrations still need the schema engine.

[gcb]

Thank you! I tested blocking the post install script (didn't read the code, just checked for side effects) and as far as I can tell, indeed, it is safe to block as it seem to download things that are downloaded on runtime anyway for the cli.

Overall it is awesome that runtime is free from the opaque binary blob now.

Also tested that PRISMA_SCHEMA_ENGINE_BINARY and PRISMA_ENGINES_MIRROR still work on v7 so that makes our old airgapped workarounds possible too.

[joshwebtimestwo]

For pre-staging the Schema Engine in @prisma/engines, there is an install-time equivalent: PRISMA_CLI_BINARY_TARGETS.

Set it in the build environment before installing dependencies, for example with npm and an existing lockfile:

PRISMA_CLI_BINARY_TARGETS=debian-openssl-3.0.x npm ci

The Prisma 7 implementation splits this variable on commas and passes those targets to the downloader. If the build machine also needs to execute a native engine, include its concrete target too, such as darwin-arm64,debian-openssl-3.0.x for an Apple Silicon builder and that Debian target.

I tested a clean installation of @prisma/engines@7.10.1 on Windows with only debian-openssl-3.0.x selected. It downloaded:

node_modules/@prisma/engines/schema-engine-debian-openssl-3.0.x

The file was a Linux ELF binary and its SHA-256 matched Prisma's published checksum. I did not execute that Linux binary or run a migration.

Ship that installed package with the deployment artifact, preserving the binary's executable permission on Linux. This covers the CLI Schema Engine; the Rust-free Prisma 7 client/adapter distinction in the previous reply still applies.

One correction to the earlier programmatic example: @prisma/engines@7.10.1 does not export download. Its exports are enginesVersion, ensureNeededBinariesExist, and getEnginesPath. The install-time setting above avoids depending on that incorrect import. Keep the engine package/version aligned with the Prisma CLI in your lockfile.

[gcb]

Interesting. Was there any reason for the change? the parameter right next to the other properties of the engine was very intuitive and convenient.

But that seems to be the solution if we ever need to distribute the cli too!