Prisma Compute

Prisma Compute

Guide agents through Prisma Compute app creation, deployment, operations, and framework-specific deploy readiness.

Prisma Compute CLI Surface

Use the Prisma Platform CLI for Compute app workflows:

bunx @prisma/cli@latest app deploy --help
bunx @prisma/cli@latest app --help
bunx @prisma/cli@latest build logs --help
bunx create-prisma@latest --help

Use @prisma/cli@latest for Compute app deployment. Use create-prisma@latest for new-project scaffolding.

Send Feedback and Report CLI Issues

The CLI has a built-in feedback channel. Use it whenever a command crashes (UNEXPECTED_ERROR), a failure survives troubleshooting, or the user asks to send feedback to the Prisma team:

bunx @prisma/cli@latest feedback "app deploy crashed: <first error line>"
bunx @prisma/cli@latest feedback "love the deploy flow" --email you@example.com

Crash output points here on its own: --json crash envelopes carry the exact pre-filled command as a recover entry in nextActions (run it verbatim), and human crash output ends with a Tell us what happened: hint. Feedback is anonymous unless --email is passed and attaches only the CLI version, node version, and OS platform/arch. Never include secrets, connection URLs, or user data in the message.

Source-of-Truth Order

Use evidence in this order when deciding what to edit or run:

1. The project's generated scripts and config, especially prisma.compute.ts, compute:deploy, framework config, and package.json.
2. CLI help output from create-prisma and @prisma/cli.
3. Local installed package code, generated artifacts, and type definitions.
4. Official docs.

When to Apply

Use this skill for:

• Creating a new app that can deploy to Prisma Compute
• Deploying an existing TypeScript app to Prisma Compute
• Creating or updating a typed prisma.compute.ts deploy config
• Deciding whether a framework is Compute-ready
• Debugging create-prisma --deploy, compute:deploy, or app deploy
• Managing Compute app logs, deployments, environment variables, and domains, and listing platform branches (branch list; there are no branch create/remove commands)
• Inspecting GitHub/Console build logs and GitHub push-to-deploy status
• Running non-interactive deploys with browser auth, multiple stored workspaces, or Prisma service tokens
• Switching, selecting, listing, or logging out local Prisma Platform workspaces for @prisma/cli
• Installing or updating Prisma skills with @prisma/cli agent install|update|status
• Sending feedback or reporting unresolvable CLI failures with @prisma/cli feedback
• Programmatic deployments with @prisma/compute-sdk or Management API integrations

Decision Tree

1. Existing project deployment or redeploy: Read references/app-deploy-cli.md.

2. Typed Compute config, monorepos, deploy targets, app roots, or build/env defaults: Read references/compute-config.md.

3. Framework-specific build/runtime work: Read references/frameworks.md.

4. New project from a scaffold: Read references/create-prisma.md.

5. Programmatic deployment, SDKs, APIs, or low-level App/Deployment concepts: Read references/sdk-api.md.

6. Build, auth, env, deploy, or runtime failures: Read references/troubleshooting.md.

Rules by Priority

Quick Rules

1. Command Verification

• verify-help-first - Use CLI help output to confirm command syntax while working.
• verify-prisma-vs-platform-cli - Do not assume prisma app deploy exists in the ORM CLI; check whether the task should use @prisma/cli.
• verify-generated-scripts - Prefer the generated compute:deploy script when a project already has one.
• verify-public-url - After a real deploy, request the public deployment URL instead of trusting local or readiness-only checks.
• verify-config-support - Treat prisma.compute.ts as the typed Compute config; inspect the project's config and generated scripts before editing or deploying.
• verify-auth-workspace-support - Use @prisma/cli auth workspace commands for local workspace list/use/logout flows.

2. Auth and Workspace Selection

• auth-source-precedence - A non-empty PRISMA_SERVICE_TOKEN is the active auth source for commands and local OAuth workspaces are ignored for execution. If it is set but empty, the CLI should fail instead of falling back to stored OAuth.
• auth-multi-workspace - auth login can store OAuth sessions for multiple workspaces on the same machine. The active workspace pointer selects which stored OAuth grant normal commands use.
• auth-list-before-switch - Use auth workspace list --json to inspect local sessions. Agents should prefer workspace ids from JSON over names because names can be ambiguous.
• auth-switch-explicitly - Use auth workspace use <id-or-name> for non-interactive switching. Use auth workspace use with no argument only for an interactive picker or when exactly one local OAuth workspace exists.
• auth-no-fallthrough - If the active OAuth workspace is logged out or fails refresh, the CLI should not silently fall through to another cached workspace. Run auth workspace use <id> to choose the next workspace.
• auth-single-workspace-logout - Use auth workspace logout <id-or-name> or auth logout --workspace <id-or-name> to remove one local OAuth workspace session. Plain auth logout clears all local OAuth workspace sessions.
• auth-service-token-switching - While PRISMA_SERVICE_TOKEN is set, auth workspace use is unavailable because the service token is the active auth source; unset the env var to switch local OAuth workspaces. Workspace logout still only cleans local OAuth state.
• auth-storage-awareness - Local OAuth credentials live in the platform auth file, with workspace metadata in a sidecar context file. Project pins live in .prisma/local.json, and CLI app/project state lives in .prisma/cli/state.json near prisma.compute.ts when present.

3. Framework Readiness

• framework-cli-first - Evaluate deploy readiness against @prisma/cli app deploy, not against what create-prisma can scaffold.
• framework-supported-cli-deploy - Compute deploy supports nextjs, nuxt, astro, hono, nestjs, tanstack-start, custom, and bun.
• framework-create-prisma-defaults-only - create-prisma can provide generated defaults and compute:deploy, but it is not the general deploy surface for existing apps.
• framework-build-output - Compute needs a server entrypoint or framework artifact, not only static output.

4. Runtime Host and Port Binding

• runtime-bind-all-interfaces - Deployed servers must bind on all interfaces (0.0.0.0 or the framework equivalent), not hard-coded localhost or 127.0.0.1.
• runtime-match-http-port - The app must listen on the deployed HTTP port: read process.env.PORT when possible, or pass the matching --http-port.
• runtime-readiness-port-only - Compute readiness watches listening ports; a loopback-only listener can look ready while public ingress cannot reach it.

5. Typed Compute Config

• config-optional-simple-app - prisma.compute.ts is not required to deploy a normal single app; use flags when there is no durable config.
• config-init-formalizer - Generate a fresh config with bunx @prisma/cli@latest init: it detects the framework, pins name/framework/httpPort (plus entry for Bun/Hono), and offers the Project link. --format json writes a dependency-free prisma.compute.json instead. init refuses when any config already exists, never scaffolds code, and never deploys.
• config-use-prisma-compute-ts - Put reusable deploy defaults in prisma.compute.ts with defineComputeConfig, not in prisma.config.ts.
• config-app-vs-apps - Use app for a single deploy target and apps for monorepos or multi-app repos; define exactly one.
• config-monorepo-roots - For monorepos, use prisma.compute.ts to declare app targets, roots, framework defaults, entrypoints, ports, and env inputs.
• config-targets - In multi-app configs, @prisma/cli app deploy web selects the apps.web target. Without [app], commands can infer the target from the current directory; otherwise deploy can run all targets while build/run require one.
• config-region-new-app-only - A config region is only a default for newly created apps; deploys to existing apps keep the app's current region.
• config-custom-artifact - Use framework: "custom" with build.outputDirectory and build.entrypoint for prebuilt or custom-built artifacts.
• config-no-project-branch-secrets - Do not commit Workspace, Project, Branch, production intent, service tokens, or secret values in prisma.compute.ts; keep those in flags, .prisma/local.json, env storage, or CI secrets. App-level defaults such as region, root, framework, entry, httpPort, and non-secret env file paths belong in config.
• config-flags-win - Explicit deploy flags such as --framework, --entry, --http-port, --region, and --env override matching config values.