CipherStashDocs
IntegrationsPrisma ORM

Prisma Compute

Deploy a CipherStash-enabled Prisma ORM 8 application on Prisma Compute.

Prisma Compute deploys TypeScript applications alongside Prisma Postgres. CipherStash has been exercised with Prisma Compute's July 2026 public beta; verify fast-moving CLI and platform details against the current Prisma documentation.

Before the first deploy

Choose a credential source

Use the developer profile locally. For CI or a deployed application, create a separate credential set with the CLI or Dashboard.

Run:

npx stash auth login

The native Stack client uses the developer profile automatically.

The local developer profile is not available on Prisma Compute. Create deployment credentials with stash env or the Dashboard, then add all four variables to both the preview and production roles.

These values are needed during the build as well as at runtime because a database module may construct cipherstashFromStack when it is imported. Prisma Compute resolves environment variables when it creates a deployment, so redeploy after changing them.

Use separate credentials for preview and production, bound to the keyset intended for each environment.

Keep native packages external

The Prisma adapter uses CipherStash's native client. For Next.js, exclude its packages from the server bundle:

next.config.ts
import type { NextConfig } from "next"

const nextConfig: NextConfig = {
  serverExternalPackages: [
    "@cipherstash/stack",
    "@cipherstash/protect-ffi",
    "@cipherstash/auth",
  ],
}

export default nextConfig

Do not select an edge runtime for routes that use this Prisma adapter.

Understand push-to-deploy

A Prisma Compute deployment runs contract emission and prisma-next db init against the target branch database.

  • Additive changes, including the EQL bundle and new encrypted columns, are reconciled during deployment.
  • Destructive changes such as dropping the old plaintext column or setting NOT NULL are rejected by the additive-only deployment policy.
  • Preview branches receive fresh databases, so a green preview does not prove that a destructive production update will succeed.

Use separate pull requests for each stage in the Prisma deployment guide.

Apply destructive migrations deliberately

After the release that stops writing the plaintext column is live, apply the reviewed destructive migration directly to the production database before merging the contract change:

npx @prisma/cli database list
npx @prisma/cli database show <database> --json
npx @prisma/cli database connection create <database-id>

npx prisma-next db update --db "<one-time-direct-url>"

npx @prisma/cli database connection remove <connection-id>

Confirm the production database by name and with database show; do not rely on list order or branch metadata. A migration applied to the wrong preview database can succeed while the production deployment continues to fail.

The destructive migration must include an apply-time coverage guard so the plaintext column is not dropped while any row lacks ciphertext.

Operational notes

  • Keep authorization checks in the page, server action, or route handler rather than relying only on Next.js middleware.
  • Runtime output and build output use different Prisma commands: app logs and build logs <build-id>.
  • A first request after scale-to-zero can cold-start; retry before treating it as an application failure.

Prisma Compute is in public beta. Reconfirm platform limitations before using it for a mission-critical workload.

On this page