wip
This commit is contained in:
@@ -0,0 +1,192 @@
|
||||
---
|
||||
name: prisma-compute
|
||||
description: Prisma Compute deployment and hosting guide. Use whenever the user mentions Prisma Compute, `prisma.compute.ts`, `defineComputeConfig`, deploying or hosting a Prisma app, `@prisma/cli app deploy`, `compute:deploy`, `create-prisma --deploy`, `PRISMA_SERVICE_TOKEN`, Compute auth/workspaces, apps/deployments/build logs/domains, localhost vs `0.0.0.0`, deploy port binding, or framework deploy readiness for Hono, Elysia, Next.js, TanStack Start, Astro, Nuxt, Svelte, Nest, Turborepo, or custom/prebuilt artifacts.
|
||||
license: MIT
|
||||
metadata:
|
||||
author: prisma
|
||||
version: "1.5.1"
|
||||
---
|
||||
|
||||
# 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:
|
||||
|
||||
```bash
|
||||
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:
|
||||
|
||||
```bash
|
||||
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`
|
||||
- Sending feedback about an unresolvable Compute CLI failure 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`](references/app-deploy-cli.md).
|
||||
|
||||
2. Typed Compute config, monorepos, deploy targets, app roots, or build/env defaults:
|
||||
Read [`references/compute-config.md`](references/compute-config.md).
|
||||
|
||||
3. Framework-specific build/runtime work:
|
||||
Read [`references/frameworks.md`](references/frameworks.md).
|
||||
|
||||
4. New project from a scaffold:
|
||||
Read [`references/create-prisma.md`](references/create-prisma.md).
|
||||
|
||||
5. Programmatic deployment, SDKs, APIs, or low-level App/Deployment concepts:
|
||||
Read [`references/sdk-api.md`](references/sdk-api.md).
|
||||
|
||||
6. Build, auth, env, deploy, or runtime failures:
|
||||
Read [`references/troubleshooting.md`](references/troubleshooting.md).
|
||||
|
||||
## Rules by Priority
|
||||
|
||||
| Priority | Category | Impact | Prefix |
|
||||
|----------|----------|--------|--------|
|
||||
| 1 | Command verification | CRITICAL | `verify-` |
|
||||
| 2 | Auth and workspace selection | CRITICAL | `auth-` |
|
||||
| 3 | Framework readiness | CRITICAL | `framework-` |
|
||||
| 4 | Runtime host and port binding | CRITICAL | `runtime-` |
|
||||
| 5 | Typed Compute config | HIGH | `config-` |
|
||||
| 6 | Branch, environment, and database wiring | HIGH | `env-` |
|
||||
| 7 | Deploy operations | HIGH | `deploy-` |
|
||||
| 8 | SDK and API automation | MEDIUM | `sdk-` |
|
||||
|
||||
## 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.
|
||||
|
||||
### 6. Branch, Environment, and Database
|
||||
|
||||
- `env-do-not-leak-secrets` - Never print full `DATABASE_URL`, service tokens, or secret values.
|
||||
- `env-deploy-loads-dotenv` - Generated deploy scripts may load env via `prisma.compute.ts` or `--env .env`; inspect the actual script/config before redeploy.
|
||||
- `env-migrations-separate` - Redeploy scripts do not run migrations or seed data. Run the appropriate Prisma database scripts separately.
|
||||
- `env-cli-token-name` - `@prisma/cli` uses `PRISMA_SERVICE_TOKEN` for service-token auth.
|
||||
- `env-branch-scope` - Branch deploys, branch env vars, and branch databases must use the same branch name; pass `--branch <git-name>` explicitly when targeting a preview branch.
|
||||
- `env-production-vs-preview` - Use `--role production` for production env, `--role preview` for preview template env, and `--branch <git-name>` for branch-specific overrides.
|
||||
- `env-db-explicit` - Keep database and env wiring explicit through database and project env commands; deploy examples should not add database setup, and deploys do not run migrations, seed data, or create one database per app automatically.
|
||||
|
||||
### 7. Deploy Operations
|
||||
|
||||
- `deploy-prod-intent` - Use `--prod --yes` only when the user intends a production deploy. The first production deploy of an App auto-promotes without `--prod`; the flag gates subsequent production-branch deploys.
|
||||
- `deploy-no-promote` - Use `app deploy --no-promote` for build-then-verify: it builds a candidate reachable at its own URL without touching the live deployment, promoted later with `app promote <deployment-id>`.
|
||||
- `deploy-github-default-branch` - When a Compute app is connected to GitHub push-to-deploy, a merge to the default branch is the production deploy path; check deployment records or GitHub check runs instead of telling users to redeploy the merged PR branch or run a default-branch preview deploy.
|
||||
- `deploy-build-logs` - Use `@prisma/cli build logs <build-id>` for GitHub/Console build output. Use `app logs` for runtime deployment logs; the two ids are different.
|
||||
- `deploy-noninteractive-auth` - Non-interactive deploys need either the correct active stored OAuth workspace or a supported service token env var; never print the token.
|
||||
- `deploy-json-for-agents` - Use `--json --no-interactive` for scripts and agent-readable output.
|
||||
- `deploy-create-project` - Use `--create-project <name>` only when the user wants deploy to create and link a new project; it conflicts with `--project` and `PRISMA_PROJECT_ID`.
|
||||
- `deploy-ops-targets` - App show/open/logs/list-deploys/promote/rollback/remove and domain commands can also accept `[app]` targets from `prisma.compute.ts`.
|
||||
- `deploy-report-cli-bugs` - On `UNEXPECTED_ERROR` or an unresolvable failure, report it with the feedback command; see "Send Feedback and Report CLI Issues" above.
|
||||
|
||||
### 8. SDK and API
|
||||
|
||||
- `sdk-use-cli-first` - Prefer `@prisma/cli app deploy` for app workflows; use `create-prisma` only to scaffold a new app unless the user is building lower-level automation.
|
||||
- `sdk-result-handling` - `@prisma/compute-sdk` returns `Result` values; check `isOk()`/`isErr()` instead of relying on exceptions.
|
||||
- `sdk-snapshot-detection` - Use `detectComputeApp` for repository snapshots that are not checked out to disk; enumerate workspaces yourself and call it once per candidate app root.
|
||||
|
||||
## Preferred Workflow
|
||||
|
||||
1. Inspect the project: package manager, template/framework, `package.json` scripts, Prisma version, Prisma client location, `prisma.compute.ts`, and existing `compute:deploy`.
|
||||
2. Verify CLI help output for the package actually being used.
|
||||
3. Verify auth context before project/app mutations: `auth whoami --json`, and when multiple local sessions may exist, `auth workspace list --json`.
|
||||
4. Choose the path:
|
||||
- existing app deploy: config-backed target when present, generated `compute:deploy`, or `@prisma/cli app build/run/deploy` flags
|
||||
- new app scaffold: `create-prisma`, then generated `compute:deploy` or `@prisma/cli app deploy`
|
||||
- low-level automation: `@prisma/compute-sdk` or Management API
|
||||
5. Check framework readiness plus host/port/env/runtime requirements, including project and branch scope.
|
||||
6. Run a local build or `app build` before deploying when feasible.
|
||||
7. Deploy with JSON output when automating, then request the public URL and summarize app URL, app id, deployment id, project id, workspace id, and follow-up steps.
|
||||
8. For GitHub/Console builds, inspect the `Prisma Compute Deploy` check run or `build logs <build-id>` before guessing why a build failed.
|
||||
|
||||
## Avoid
|
||||
|
||||
- Do not bury Compute deployment guidance in the generic `prisma-cli` skill.
|
||||
- Do not run `create-prisma` inside an existing app just to deploy it; use the generated `compute:deploy` script or `@prisma/cli app deploy`.
|
||||
- Do not tell users that every `create-prisma` template can auto-deploy.
|
||||
- Do not deploy with placeholder `DATABASE_URL` values.
|
||||
- Do not assume `next start` is the Compute runtime path; Next.js deploys need standalone output.
|
||||
@@ -0,0 +1,403 @@
|
||||
# Prisma Platform CLI App Deploy
|
||||
|
||||
Use this reference for existing projects and for generated `compute:deploy` scripts.
|
||||
|
||||
## Package and Command
|
||||
|
||||
Compute app workflows are exposed through the Prisma Platform CLI package:
|
||||
|
||||
```bash
|
||||
bunx @prisma/cli@latest --help
|
||||
bunx @prisma/cli@latest app --help
|
||||
bunx @prisma/cli@latest app deploy --help
|
||||
bunx @prisma/cli@latest build logs --help
|
||||
```
|
||||
|
||||
The examples in help output may call the binary `prisma-cli`. When using package runners, prefer:
|
||||
|
||||
```bash
|
||||
bunx @prisma/cli@latest app deploy
|
||||
npx @prisma/cli@latest app deploy
|
||||
pnpm dlx @prisma/cli@latest app deploy
|
||||
```
|
||||
|
||||
## Agent Skill Installation
|
||||
|
||||
`@prisma/cli` can install and refresh Prisma skills for local AI coding agents:
|
||||
|
||||
```bash
|
||||
bunx @prisma/cli@latest agent install
|
||||
bunx @prisma/cli@latest agent install --skill prisma-compute
|
||||
bunx @prisma/cli@latest agent update
|
||||
bunx @prisma/cli@latest agent status --json
|
||||
```
|
||||
|
||||
`agent install` and `agent update` shell out to `skills@latest add prisma/skills` through the detected package runner. Use them when the user wants Prisma's agent context installed or refreshed; they are not a deployment command.
|
||||
|
||||
## Typed Compute Config
|
||||
|
||||
`prisma.compute.ts` is optional for normal single-app deploys and useful for reusable defaults or multi-app targets. Read [`compute-config.md`](compute-config.md) for config shapes, target selection, precedence, and monorepo rules. This reference only shows how deploy commands consume those settings.
|
||||
|
||||
## Auth and Project Binding
|
||||
|
||||
Useful commands:
|
||||
|
||||
```bash
|
||||
bunx @prisma/cli@latest auth login
|
||||
bunx @prisma/cli@latest auth whoami
|
||||
bunx @prisma/cli@latest project list --json
|
||||
bunx @prisma/cli@latest project show
|
||||
bunx @prisma/cli@latest project link <project-id-or-name>
|
||||
```
|
||||
|
||||
`@prisma/cli` can keep multiple local browser-login workspace sessions. Running `auth login` again for a different workspace should add/update that workspace session and make it active; it should not delete the existing workspace session. The active workspace pointer decides which stored OAuth workspace normal commands use.
|
||||
|
||||
For agents, prefer this flow before project/app mutations:
|
||||
|
||||
```bash
|
||||
bunx @prisma/cli@latest auth whoami --json
|
||||
bunx @prisma/cli@latest auth workspace list --json
|
||||
bunx @prisma/cli@latest auth workspace use <workspace-id>
|
||||
```
|
||||
|
||||
Use workspace ids from `auth workspace list --json` when possible. Names are friendlier for humans but can be ambiguous. Use `auth workspace use` with no argument for a human interactive picker; headless scripts should pass an id because no-argument `use` fails non-interactively when multiple local OAuth workspaces exist.
|
||||
|
||||
If the active workspace is logged out or its refresh fails, the CLI intentionally does not auto-select another cached workspace. Choose the next workspace explicitly:
|
||||
|
||||
Use `auth workspace list --json`, then `auth workspace use <workspace-id>`.
|
||||
|
||||
To clean up one local OAuth workspace without clearing every stored workspace session:
|
||||
|
||||
```bash
|
||||
bunx @prisma/cli@latest auth workspace logout <workspace-id-or-name>
|
||||
# equivalent:
|
||||
bunx @prisma/cli@latest auth logout --workspace <workspace-id-or-name>
|
||||
```
|
||||
|
||||
Plain `auth logout` clears all local OAuth workspace sessions. It does not unset `PRISMA_SERVICE_TOKEN`.
|
||||
|
||||
For a new linked project:
|
||||
|
||||
```bash
|
||||
bunx @prisma/cli@latest project create my-app --json
|
||||
```
|
||||
|
||||
For non-interactive or CI work, `@prisma/cli` accepts a workspace service token through `PRISMA_SERVICE_TOKEN`. A non-empty service token takes precedence over stored browser-login credentials, so local OAuth workspace switching does not affect command execution while the env var is set. `auth workspace list --json` may still show local OAuth sessions, but they are not switchable until the service-token env var is unset. Verify auth with `auth whoami` and never print the token value.
|
||||
|
||||
If `PRISMA_SERVICE_TOKEN` is set but empty, unset it or provide a real token. The CLI should fail instead of silently falling back to local OAuth credentials.
|
||||
|
||||
Local auth storage is useful for debugging but should not be printed verbatim:
|
||||
|
||||
- `PRISMA_COMPUTE_AUTH_FILE` can override the auth file path.
|
||||
- On macOS, the default OAuth credentials file is `~/Library/Application Support/prisma/auth.json`.
|
||||
- Workspace metadata and the active workspace pointer live beside it as `auth.context.json`.
|
||||
- Project pins live in `.prisma/local.json`.
|
||||
- Local CLI state such as selected app and known live deployment lives in `.prisma/cli/state.json`, rooted near `prisma.compute.ts` when a config is discovered.
|
||||
|
||||
## Project, Branch, Database, and Env Scope
|
||||
|
||||
Compute deploys resolve a target project, app, and branch. Be explicit when the user's intent is not the already linked default project/app:
|
||||
|
||||
```bash
|
||||
bunx @prisma/cli@latest project show --json
|
||||
bunx @prisma/cli@latest app deploy --project proj_123 --app my-api --branch feature/login --json
|
||||
```
|
||||
|
||||
If `prisma.compute.ts` defines a `name` or an `apps` key, that config can provide the app name. `--app` and `PRISMA_APP_ID` rank above the config value. `[app]` selects a target from `apps`:
|
||||
|
||||
```bash
|
||||
bunx @prisma/cli@latest app deploy api --project proj_123 --branch feature/login --json
|
||||
```
|
||||
|
||||
See [`compute-config.md`](compute-config.md) for no-argument target inference, deploy-all, and build/run target rules.
|
||||
|
||||
Branch scope must line up across deploys, databases, and env vars:
|
||||
|
||||
- `app deploy --branch <git-name>` creates a deployment for that branch.
|
||||
- `database create <name> --branch <git-name>` creates a Prisma Postgres database for that branch scope.
|
||||
- `project env add/update/list/remove --branch <git-name>` manages branch-specific env overrides.
|
||||
- `project env add/update/list/remove --role production` manages production env.
|
||||
- `project env add/update/list/remove --role preview` manages preview-template env.
|
||||
|
||||
Do not assume a local Git branch was used by the CLI unless the generated script or command output says so. If a user asks for `feature/login`, pass `--branch feature/login` consistently to app, database, and env commands.
|
||||
|
||||
Promotion is a separate production action: `app promote <deployment-id>` rebuilds a deployment with production env vars. Do not treat a preview branch deploy as production promotion.
|
||||
|
||||
## Deployment Story: GitHub vs CLI
|
||||
|
||||
When a Compute app is connected to GitHub push-to-deploy, the default branch is the production deploy path. If a PR has been merged into `main` or another configured default branch, the natural answer is that the changes should appear in production after the production deployment completes; use CLI deploys for explicit manual deploys, local-source deploys, or repositories that are not using GitHub push-to-deploy.
|
||||
|
||||
`app show`, `app list-deploys`, and `app logs` expose `--app`, `--project`, and for logs `--deployment`, not `--branch`. For branch debugging, capture the deployment id from deploy JSON and inspect that deployment or its logs.
|
||||
|
||||
`app deploy --create-project <name>` creates and links a new Project before deploying. Use it only when the user wants a new Project. It conflicts with `--project` and `PRISMA_PROJECT_ID`, and `--yes` alone does not choose Project scope.
|
||||
|
||||
`app deploy --region <region>` only applies when deploy creates a new app. Existing apps keep their current region. Use `prisma.compute.ts` `region` for a durable default, and use the flag only for one-off new-app placement.
|
||||
|
||||
## Database and Env
|
||||
|
||||
Create a Prisma Postgres database for the linked project:
|
||||
|
||||
```bash
|
||||
bunx @prisma/cli@latest database create main --branch main --json
|
||||
```
|
||||
|
||||
Manage project env vars:
|
||||
|
||||
```bash
|
||||
bunx @prisma/cli@latest project env list
|
||||
bunx @prisma/cli@latest project env add --file .env --role production
|
||||
bunx @prisma/cli@latest project env add --file .env.preview --role preview
|
||||
bunx @prisma/cli@latest project env add DATABASE_URL=postgresql://... --branch feature/foo
|
||||
bunx @prisma/cli@latest project env update --file .env --role production
|
||||
bunx @prisma/cli@latest project env update DATABASE_URL=postgresql://... --branch feature/foo
|
||||
bunx @prisma/cli@latest project env list --branch feature/foo
|
||||
bunx @prisma/cli@latest project env remove STRIPE_KEY --role preview
|
||||
```
|
||||
|
||||
`app deploy --env .env` loads environment variables from a file for the deployment. A config-backed deploy can instead load env through `prisma.compute.ts` `env`. Neither path is a migration command or seed command.
|
||||
|
||||
Database setup is not part of `prisma.compute.ts`. Keep database intent explicit with `database create` and project env commands. Do not add database setup to deploy examples. Treat any generated connection URL as a one-time secret.
|
||||
|
||||
Database and env guardrails:
|
||||
|
||||
- Deploys do not run migrations, seed data, or schema push. Run the app's own Prisma database command after deploy setup when needed.
|
||||
- In deploy-all, every target on the same branch shares branch-scoped project env unless you assign app-specific env values yourself.
|
||||
- Existing database env values supplied through `--env DATABASE_URL=...`, `--env DIRECT_URL=...`, an env file, or project env should be treated as the source of truth.
|
||||
- Known non-PostgreSQL Prisma schema sources should not be wired to Prisma Postgres automatically.
|
||||
|
||||
## Project Git, Branch, and Database Operations
|
||||
|
||||
These commands are part of the same Platform CLI surface and often matter while preparing Compute deploys:
|
||||
|
||||
```bash
|
||||
bunx @prisma/cli@latest branch list --json
|
||||
bunx @prisma/cli@latest git connect git@github.com:org/repo.git --project proj_123
|
||||
bunx @prisma/cli@latest git disconnect --project proj_123
|
||||
bunx @prisma/cli@latest database list --branch feature/foo --json
|
||||
bunx @prisma/cli@latest database show db_123 --json
|
||||
bunx @prisma/cli@latest database remove db_123 --confirm db_123
|
||||
bunx @prisma/cli@latest database connection list db_123 --json
|
||||
bunx @prisma/cli@latest database connection create db_123 --name readonly
|
||||
bunx @prisma/cli@latest database connection remove conn_123 --confirm conn_123
|
||||
bunx @prisma/cli@latest database connection rotate conn_123 --confirm conn_123
|
||||
bunx @prisma/cli@latest database usage db_123 --json
|
||||
bunx @prisma/cli@latest database backup list db_123 --json
|
||||
bunx @prisma/cli@latest database restore db_123 --backup bkp_123 --confirm db_123
|
||||
bunx @prisma/cli@latest project rename new-name --project proj_123
|
||||
bunx @prisma/cli@latest project transfer proj_123 --to-workspace wksp_456 --confirm proj_123
|
||||
bunx @prisma/cli@latest project remove proj_123 --confirm proj_123
|
||||
```
|
||||
|
||||
Destructive and ownership-changing commands (`remove`, `restore`, `transfer`, `connection rotate`) require exact `--confirm <id>`; `--yes` is not enough.
|
||||
|
||||
Git integration connects a Project to a GitHub repository. Console-side GitHub import can create a Compute app and trigger push-to-deploy for the connected repository, including default-branch production deploys. The CLI `git connect` command is setup, not a local deploy command; use `app deploy` for explicit CLI deploys.
|
||||
|
||||
For GitHub-driven deploys, inspect the Console/build-runner state, deployment records, build logs, or the `Prisma Compute Deploy` GitHub check run instead of assuming local CLI output exists. The build runner can perform branch-aware database/env wiring: a preview branch with a Prisma schema and no `DATABASE_URL` can get a branch-scoped preview database, while production can wire a missing `DATABASE_URL` template from an existing ready database. GitHub check runs are the guided feedback path; do not promise Vercel-style PR comments.
|
||||
|
||||
Database and database-connection commands never print stored secret values in list/show output. `database create` and `database connection create` return a one-time connection URL; treat it as a secret, store it immediately in env if needed, and do not echo it back in summaries. Removal requires exact `--confirm <id>`; `--yes` is not enough.
|
||||
|
||||
## Build and Run Locally
|
||||
|
||||
Before deploy, verify that the app can produce a Compute artifact:
|
||||
|
||||
```bash
|
||||
bunx @prisma/cli@latest app build --build-type auto
|
||||
bunx @prisma/cli@latest app run --build-type auto --port 3000
|
||||
```
|
||||
|
||||
For Bun/server entrypoints:
|
||||
|
||||
```bash
|
||||
bunx @prisma/cli@latest app build --build-type bun --entry src/index.ts
|
||||
bunx @prisma/cli@latest app run --build-type bun --entry src/index.ts --port 8080
|
||||
```
|
||||
|
||||
For NestJS, use `app build` to validate the Compute artifact and run the framework's own dev command locally:
|
||||
|
||||
```bash
|
||||
bunx @prisma/cli@latest app build --build-type nestjs
|
||||
bun run dev
|
||||
```
|
||||
|
||||
With a compute config, pass the target name instead of repeating framework/entry/port flags:
|
||||
|
||||
```bash
|
||||
bunx @prisma/cli@latest app build api
|
||||
bunx @prisma/cli@latest app run api --port 8080
|
||||
```
|
||||
|
||||
`app run --port` sets `PORT` for local development. It does not rewrite an app's explicit host binding, so a local run is not enough to prove the deployed server is reachable from ingress.
|
||||
|
||||
`app run --build-type nestjs` is not supported. If a config-backed NestJS target is selected, run the Nest dev server directly instead.
|
||||
|
||||
## Deploy
|
||||
|
||||
Deploy with prompts:
|
||||
|
||||
```bash
|
||||
bunx @prisma/cli@latest app deploy
|
||||
```
|
||||
|
||||
Agent/script-friendly deploy (do not assume production; add `--prod --yes` only when the user intends a production deploy, and note the first production deploy of an App auto-promotes without `--prod`):
|
||||
|
||||
```bash
|
||||
bunx @prisma/cli@latest app deploy \
|
||||
--json \
|
||||
--no-interactive \
|
||||
--env .env
|
||||
```
|
||||
|
||||
Build-then-verify path for CI: `--no-promote` builds a candidate deployment without changing the live one; it is reachable at its own candidate URL and promoted later with `app promote <deployment-id>`:
|
||||
|
||||
```bash
|
||||
bunx @prisma/cli@latest app deploy --no-promote --json --no-interactive
|
||||
```
|
||||
|
||||
For preview branches, omit `--prod` unless the user explicitly intends a production deploy:
|
||||
|
||||
```bash
|
||||
bunx @prisma/cli@latest app deploy \
|
||||
--branch feature/foo \
|
||||
--json \
|
||||
--no-interactive \
|
||||
--env .env.preview
|
||||
```
|
||||
|
||||
After a real deploy, verify the public deployment URL. Do not stop at "deploy succeeded" or a local `app run` check:
|
||||
|
||||
```bash
|
||||
curl -i https://<deployment-url>
|
||||
```
|
||||
|
||||
If the deploy command returns JSON, parse the URL from the result and request that exact public URL. Do not accidentally test `localhost` or `127.0.0.1` instead of public ingress.
|
||||
|
||||
Create/link a project during deploy:
|
||||
|
||||
```bash
|
||||
bunx @prisma/cli@latest app deploy \
|
||||
--create-project my-app \
|
||||
--prod \
|
||||
--yes \
|
||||
--env .env
|
||||
```
|
||||
|
||||
Deploy with framework and port:
|
||||
|
||||
```bash
|
||||
bunx @prisma/cli@latest app deploy \
|
||||
--framework hono \
|
||||
--http-port 8080 \
|
||||
--prod \
|
||||
--yes \
|
||||
--env .env
|
||||
```
|
||||
|
||||
Deploy a newly created app in a specific region:
|
||||
|
||||
```bash
|
||||
bunx @prisma/cli@latest app deploy \
|
||||
--app my-api \
|
||||
--region us-west-1 \
|
||||
--prod \
|
||||
--yes \
|
||||
--env .env
|
||||
```
|
||||
|
||||
`--region` is a new-app placement hint. It does not move an existing app.
|
||||
|
||||
Deploy a preview branch with framework and port:
|
||||
|
||||
```bash
|
||||
bunx @prisma/cli@latest app deploy \
|
||||
--framework hono \
|
||||
--branch feature/foo \
|
||||
--http-port 8080 \
|
||||
--json \
|
||||
--no-interactive \
|
||||
--env .env.preview
|
||||
```
|
||||
|
||||
Bun-style app with explicit entrypoint:
|
||||
|
||||
```bash
|
||||
bunx @prisma/cli@latest app deploy \
|
||||
--framework bun \
|
||||
--entry src/index.ts \
|
||||
--http-port 8080 \
|
||||
--prod \
|
||||
--yes \
|
||||
--env .env
|
||||
```
|
||||
|
||||
`--entry <path>` without `--framework` is treated as a Bun app deploy.
|
||||
|
||||
Config-backed Bun-style app:
|
||||
|
||||
```bash
|
||||
bunx @prisma/cli@latest app deploy api --prod --yes --env .env
|
||||
```
|
||||
|
||||
Use config for stable app defaults, and flags for one-off project, branch, region, env, and production choices. Keep database setup in explicit database and project-env commands.
|
||||
|
||||
## Operations
|
||||
|
||||
Inspect and open:
|
||||
|
||||
```bash
|
||||
bunx @prisma/cli@latest app show --json
|
||||
bunx @prisma/cli@latest app open
|
||||
```
|
||||
|
||||
Deployments:
|
||||
|
||||
```bash
|
||||
bunx @prisma/cli@latest app list-deploys --json
|
||||
bunx @prisma/cli@latest app show-deploy <deployment-id> --json
|
||||
bunx @prisma/cli@latest app promote <deployment-id> --yes
|
||||
bunx @prisma/cli@latest app rollback --to <deployment-id> --yes
|
||||
bunx @prisma/cli@latest app remove --app my-api --yes
|
||||
```
|
||||
|
||||
Logs:
|
||||
|
||||
```bash
|
||||
bunx @prisma/cli@latest app logs
|
||||
bunx @prisma/cli@latest app logs --deployment <deployment-id>
|
||||
bunx @prisma/cli@latest app logs --json
|
||||
```
|
||||
|
||||
Build logs for GitHub/Console builds:
|
||||
|
||||
```bash
|
||||
bunx @prisma/cli@latest build logs <build-id>
|
||||
bunx @prisma/cli@latest build logs <build-id> --follow
|
||||
bunx @prisma/cli@latest build logs <build-id> --json
|
||||
```
|
||||
|
||||
`build logs` streams build output keyed by a Build id from a GitHub/Console build or check run. It is separate from runtime `app logs`, which are keyed by the current app deployment or a deployment id.
|
||||
|
||||
Domains:
|
||||
|
||||
```bash
|
||||
bunx @prisma/cli@latest app domain add shop.example.com
|
||||
bunx @prisma/cli@latest app domain show shop.example.com
|
||||
bunx @prisma/cli@latest app domain wait shop.example.com --timeout 15m
|
||||
bunx @prisma/cli@latest app domain retry shop.example.com
|
||||
bunx @prisma/cli@latest app domain remove shop.example.com
|
||||
```
|
||||
|
||||
Custom domain commands target production branch runtime. Do not use a preview branch for production domain setup.
|
||||
|
||||
## Output Handling
|
||||
|
||||
When `--json` is available, parse the JSON and summarize:
|
||||
|
||||
- project id/name
|
||||
- branch name
|
||||
- app id/name
|
||||
- deployment id/status
|
||||
- build id when present
|
||||
- deployment URL
|
||||
- database id/name if one was created
|
||||
|
||||
Do not print secret env var values.
|
||||
@@ -0,0 +1,222 @@
|
||||
# Prisma Compute Config
|
||||
|
||||
Use this reference when creating or updating `prisma.compute.ts`, especially for monorepos, multi-app deploys, reusable framework defaults, env inputs, ports, entrypoints, or build settings.
|
||||
|
||||
`prisma.compute.ts` is not required for every deploy. A simple app can deploy with `@prisma/cli app deploy --framework ... --entry ... --http-port ... --env ...`. The config file exists to make those app-level defaults typed and repeatable.
|
||||
|
||||
For monorepos or multi-app repositories, use `prisma.compute.ts`: it is the practical way to tell Compute which app target lives at which `root` and which framework/entry/env defaults belong to each target.
|
||||
|
||||
## Generating a Config with `init`
|
||||
|
||||
Prefer `bunx @prisma/cli@latest init` over hand-writing a fresh single-app config. It detects the framework from the same registry deploy uses, pins `name`, `framework`, and `httpPort` (plus `entry` for Bun and Hono), previews every value with its source, offers the `@prisma/compute-sdk` devDependency for editor types, and offers the Project link. Useful flags: `--framework`, `--entry`, `--http-port`, `--name`, `--no-link`, `--json`.
|
||||
|
||||
`--format json` writes a dependency-free static `prisma.compute.json` instead of the TypeScript config; a later explicit `init --format ts` converts it in place when the config needs to become programmatic. `init` fails with `INIT_CONFIG_EXISTS` when any compute config already exists, never scaffolds application code, and never deploys. Multi-app monorepo configs are still written by hand.
|
||||
|
||||
## File Names and Discovery
|
||||
|
||||
The canonical file is `prisma.compute.ts`. The loader also accepts:
|
||||
|
||||
```text
|
||||
prisma.compute.mts
|
||||
prisma.compute.js
|
||||
prisma.compute.mjs
|
||||
prisma.compute.cjs
|
||||
prisma.compute.json
|
||||
```
|
||||
|
||||
`prisma.compute.json` is the static, dependency-free variant of the same config; it is discovered and loaded like the others.
|
||||
|
||||
Keep exactly one compute config file in a directory. If multiple names exist together, the CLI reports `COMPUTE_CONFIG_INVALID`.
|
||||
|
||||
The CLI searches from the invocation directory up to the repository or workspace boundary. Boundaries include `.git`, `pnpm-workspace.yaml`, `bun.lock`, `bun.lockb`, or `package.json#workspaces`. Config-relative paths such as `root` and `env.file` resolve from the config file directory. `--env` flag paths still resolve from the invocation directory.
|
||||
|
||||
When a config is discovered, its directory becomes the Compute project directory for local state: `.prisma/local.json` and `.prisma/cli/state.json` live beside that config, not necessarily inside the app root.
|
||||
|
||||
## Basic Shape
|
||||
|
||||
Import `defineComputeConfig` from `@prisma/compute-sdk/config`. The CLI aliases this helper when loading the config, so the command can evaluate the config without a local SDK install solely for runtime loading.
|
||||
|
||||
```typescript
|
||||
import { defineComputeConfig } from "@prisma/compute-sdk/config";
|
||||
|
||||
export default defineComputeConfig({
|
||||
app: {
|
||||
name: "api",
|
||||
framework: "hono",
|
||||
httpPort: 8080,
|
||||
env: ".env",
|
||||
},
|
||||
});
|
||||
```
|
||||
|
||||
JavaScript configs can default-export a plain object, but prefer `prisma.compute.ts` for type checking.
|
||||
|
||||
Define exactly one of:
|
||||
|
||||
- `app` for a single deploy target
|
||||
- `apps` for a monorepo or multi-app repository
|
||||
|
||||
Do not define both. Besides `app`/`apps`, the only other allowed top-level key is `region`: a project-level default region applied when deploy creates new apps, overridable per app and by `--region`.
|
||||
|
||||
## App Fields
|
||||
|
||||
Each app target accepts:
|
||||
|
||||
| Field | Meaning |
|
||||
|-------|---------|
|
||||
| `name` | Deployed app name. Defaults to the `apps` key, then CLI inference. |
|
||||
| `region` | Compute region id used only when deploy creates a new app. Existing apps keep their current region. |
|
||||
| `root` | App directory relative to the config file. Defaults to the config directory. |
|
||||
| `framework` | Deploy framework: `nextjs`, `nuxt`, `astro`, `hono`, `nestjs`, `tanstack-start`, `custom`, or `bun`. |
|
||||
| `entry` | Entrypoint path for Bun/Hono-style deploys, relative to the app root. |
|
||||
| `httpPort` | Deployed HTTP port. Use this for fixed-port apps. |
|
||||
| `env` | Dotenv file path string, or `{ file, vars }`. Paths resolve from the config directory. |
|
||||
| `build` | `{ command, outputDirectory, entrypoint }`. Present means the config owns build settings for that target. |
|
||||
|
||||
`env` examples:
|
||||
|
||||
```typescript
|
||||
export default defineComputeConfig({
|
||||
app: {
|
||||
framework: "nextjs",
|
||||
env: {
|
||||
file: [".env", ".env.production"],
|
||||
vars: {
|
||||
NODE_ENV: "production",
|
||||
},
|
||||
},
|
||||
},
|
||||
});
|
||||
```
|
||||
|
||||
Do not put secrets directly in committed `vars`. Keep secret values in platform env, CI secrets, or dotenv files that are intentionally managed outside version control.
|
||||
|
||||
`build` examples:
|
||||
|
||||
```typescript
|
||||
export default defineComputeConfig({
|
||||
app: {
|
||||
framework: "nextjs",
|
||||
build: {
|
||||
command: "pnpm build",
|
||||
outputDirectory: ".next/standalone",
|
||||
},
|
||||
},
|
||||
});
|
||||
```
|
||||
|
||||
Use `command: null` to skip the build step only when the app root already contains the deployable artifact.
|
||||
|
||||
For a custom or prebuilt artifact, make the deploy target explicit:
|
||||
|
||||
```typescript
|
||||
export default defineComputeConfig({
|
||||
app: {
|
||||
framework: "custom",
|
||||
build: {
|
||||
command: "npm run build",
|
||||
outputDirectory: "build",
|
||||
entrypoint: "handler.js",
|
||||
},
|
||||
},
|
||||
});
|
||||
```
|
||||
|
||||
`build.entrypoint` is relative to `build.outputDirectory` when an output directory is set. For Bun/Hono configs without an output directory, an entrypoint-backed build can supply the source entrypoint. Do not set both `entry` and `build.entrypoint` unless they describe the same file.
|
||||
|
||||
A config `build` block is accepted for every supported framework: the config-backed build types are `nextjs`, `nuxt`, `astro`, `nestjs`, `tanstack-start`, `custom`, and `bun` (`hono` builds through the `bun` strategy). Only `custom` requires one (`build.outputDirectory` and `build.entrypoint`); for the others it overrides inferred build settings.
|
||||
|
||||
## Monorepos and Multi-App Repos
|
||||
|
||||
For monorepos, put `prisma.compute.ts` at the repo or workspace root and use `apps`. This keeps project binding and local `.prisma/` state at the repo root while each app builds from its own `root`.
|
||||
|
||||
```typescript
|
||||
import { defineComputeConfig } from "@prisma/compute-sdk/config";
|
||||
|
||||
export default defineComputeConfig({
|
||||
apps: {
|
||||
web: {
|
||||
root: "apps/web",
|
||||
framework: "nextjs",
|
||||
env: "apps/web/.env",
|
||||
},
|
||||
api: {
|
||||
root: "apps/api",
|
||||
framework: "hono",
|
||||
entry: "src/index.ts",
|
||||
httpPort: 8080,
|
||||
env: {
|
||||
file: "apps/api/.env",
|
||||
vars: {
|
||||
LOG_LEVEL: "info",
|
||||
},
|
||||
},
|
||||
},
|
||||
frontend: {
|
||||
root: "apps/frontend",
|
||||
framework: "custom",
|
||||
build: {
|
||||
command: "pnpm --filter frontend build",
|
||||
outputDirectory: "dist/server",
|
||||
entrypoint: "index.mjs",
|
||||
},
|
||||
},
|
||||
},
|
||||
});
|
||||
```
|
||||
|
||||
Target selection:
|
||||
|
||||
```bash
|
||||
bunx @prisma/cli@latest app deploy web
|
||||
bunx @prisma/cli@latest app deploy api
|
||||
bunx @prisma/cli@latest app build api
|
||||
bunx @prisma/cli@latest app run api --port 8080
|
||||
```
|
||||
|
||||
If no `[app]` argument is passed, commands can infer the target from the invocation directory when it is inside a configured `root`. The deepest matching root wins. If no target is inferred from a multi-app config, a bare deploy can deploy all targets in declaration order:
|
||||
|
||||
```bash
|
||||
bunx @prisma/cli@latest app deploy --branch feature/foo --json --no-interactive
|
||||
```
|
||||
|
||||
Deploy-all rejects per-app overrides such as `--app`, `--framework`, `--entry`, `--http-port`, `--region`, `--env`, and `PRISMA_APP_ID`. Project, branch, production, and confirmation flags still apply to the whole run. Keep database setup in explicit database and project-env commands.
|
||||
|
||||
`app build` and `app run` still need one target in multi-app configs because a local build/run command cannot operate N apps at once.
|
||||
|
||||
Additional target rules:
|
||||
|
||||
- A single-entry `apps` map can deploy its only target without an argument.
|
||||
- With a single `app` config, `[app]` is accepted only when it equals the configured `name`.
|
||||
- `[app]` without any compute config file is a usage error.
|
||||
|
||||
## Precedence
|
||||
|
||||
Explicit flags win over config values:
|
||||
|
||||
- `--framework` overrides `framework`
|
||||
- `--entry` overrides `entry`
|
||||
- `--http-port` overrides `httpPort`
|
||||
- `--region` overrides `region`
|
||||
- any `--env` flag replaces all config env inputs
|
||||
- `--app` and `PRISMA_APP_ID` rank above config app names
|
||||
|
||||
`region` is not an app selector. Config `region` and `--region` are only used when deploy creates a new app. If the selected app already exists, deploy keeps that app's existing region.
|
||||
|
||||
`prisma.compute.ts` never selects Workspace, Project, Branch, or production intent. Keep those in CLI flags, environment variables, `.prisma/local.json`, or CI configuration:
|
||||
|
||||
```bash
|
||||
bunx @prisma/cli@latest app deploy api \
|
||||
--project proj_123 \
|
||||
--branch feature/foo \
|
||||
--prod \
|
||||
--yes
|
||||
```
|
||||
|
||||
## Database Scope
|
||||
|
||||
The config does not declare databases. Keep database intent in `database create`, project env commands, or external automation. Read [`app-deploy-cli.md`](app-deploy-cli.md) for deploy-all, migration, and env-var guardrails.
|
||||
|
||||
## Relationship to `prisma.config.ts`
|
||||
|
||||
Do not put Compute deploy defaults in `prisma.config.ts`. Prisma ORM uses `prisma.config.ts`, while Compute uses `prisma.compute.ts`.
|
||||
@@ -0,0 +1,117 @@
|
||||
# create-prisma Compute Flow
|
||||
|
||||
Use this reference when creating a new app with Prisma and optionally deploying it to Prisma Compute.
|
||||
|
||||
Do not use `create-prisma` as the deploy path for an existing app. For existing projects, use the generated `compute:deploy` script when present, or call `bunx @prisma/cli@latest app deploy` directly.
|
||||
|
||||
## Reference
|
||||
|
||||
Useful scaffold checks:
|
||||
|
||||
```bash
|
||||
bunx create-prisma@latest --help
|
||||
bunx create-prisma@latest --version
|
||||
```
|
||||
|
||||
Use `create-prisma@latest` for new-project scaffolding.
|
||||
|
||||
## Supported Templates
|
||||
|
||||
`create-prisma@latest` scaffolds `hono`, `elysia`, `nest`, `next`, `svelte`, `astro`, `nuxt`, `tanstack-start`, and `turborepo`.
|
||||
|
||||
Integrated `--deploy` support applies to `hono`, `elysia`, `nest`, `next`, `astro`, `nuxt`, `tanstack-start`, and `turborepo`. For `turborepo`, the generated config target is usually `api`.
|
||||
|
||||
The scaffold template name is `nest`, but the Compute deploy framework/config key is `nestjs`.
|
||||
|
||||
`svelte` is scaffold-only for Compute because `@prisma/cli app deploy --framework` has no `svelte` key.
|
||||
|
||||
## Basic Commands
|
||||
|
||||
Interactive creation:
|
||||
|
||||
```bash
|
||||
bunx create-prisma@latest
|
||||
```
|
||||
|
||||
Non-interactive scaffold only:
|
||||
|
||||
```bash
|
||||
bunx create-prisma@latest \
|
||||
--name my-api \
|
||||
--template hono \
|
||||
--provider postgresql \
|
||||
--no-install \
|
||||
--no-generate \
|
||||
--no-migrate-and-seed \
|
||||
--no-deploy
|
||||
```
|
||||
|
||||
Create and deploy a supported template:
|
||||
|
||||
```bash
|
||||
bunx create-prisma@latest \
|
||||
--name my-api \
|
||||
--template hono \
|
||||
--provider postgresql \
|
||||
--deploy
|
||||
```
|
||||
|
||||
## PostgreSQL and Database Behavior
|
||||
|
||||
With PostgreSQL, no explicit `--database-url`, and no `--no-prisma-postgres`, the Compute flow can create:
|
||||
|
||||
- a Prisma Compute project
|
||||
- a `main` Prisma Postgres database on the `main` branch
|
||||
- a `.env` file containing `DATABASE_URL`
|
||||
- an initial Compute deployment with env vars loaded from `.env`
|
||||
|
||||
`create-prisma` is the new-project path. If the user needs a later preview branch deploy, use the generated `compute:deploy` script or `@prisma/cli app deploy --branch <git-name>` after the app exists. Keep branch names aligned across `app deploy --branch`, `database create --branch`, and `project env ... --branch`.
|
||||
|
||||
For unattended local tests, pass `--no-prisma-postgres` unless you intentionally want provisioning:
|
||||
|
||||
```bash
|
||||
bunx create-prisma@latest \
|
||||
--name smoke-app \
|
||||
--template hono \
|
||||
--provider postgresql \
|
||||
--no-prisma-postgres \
|
||||
--database-url "postgresql://USER:PASSWORD@HOST:PORT/DB" \
|
||||
--no-deploy
|
||||
```
|
||||
|
||||
Do not deploy placeholder database URLs. If `DATABASE_URL` came from a placeholder default, omit it from deploy env and ask the user for a real production database.
|
||||
|
||||
## Generated Deploy Script
|
||||
|
||||
When the deploy flow is selected, `create-prisma` can add:
|
||||
|
||||
```json
|
||||
{
|
||||
"scripts": {
|
||||
"compute:deploy": "bunx @prisma/cli@latest app deploy --prod --yes ..."
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
Use the actual generated script from `package.json`; do not reconstruct it from memory. The script redeploys app code using generated flags and/or `prisma.compute.ts`. It does not create a new project, create a new database, run migrations, or seed data. If a scaffolded project does not have `compute:deploy`, use `@prisma/cli app deploy` directly.
|
||||
|
||||
Inspect the generated `package.json`, `prisma.compute.ts`, and README before editing deploy behavior.
|
||||
|
||||
## Generated Files to Preserve
|
||||
|
||||
Preserve generated framework runtime files and `prisma.compute.ts` unless you are intentionally changing the deploy target. For framework-specific deploy/runtime details, read [`frameworks.md`](frameworks.md).
|
||||
|
||||
All Prisma 7 scaffolds:
|
||||
|
||||
- use `prisma.config.ts`
|
||||
- load `dotenv/config` where the runtime supports it
|
||||
- generate Prisma Client into a template-local path such as `src/generated/prisma`
|
||||
- use `@prisma/adapter-pg` with a `DATABASE_URL` connection string for PostgreSQL
|
||||
|
||||
## Addon Notes
|
||||
|
||||
`create-prisma` supports `--skills`, `--mcp`, and `--extension`. Those are separate from Compute deployment. Do not imply that enabling skills or MCP deploys the app.
|
||||
|
||||
## Failure Handling
|
||||
|
||||
If `--deploy` is explicit and setup cannot authenticate, cannot run the Platform CLI, or cannot complete the integrated deploy, report that deploy failed and keep the scaffolded project. Do not delete the user's files.
|
||||
@@ -0,0 +1,382 @@
|
||||
# Prisma Compute Framework Readiness
|
||||
|
||||
Use this reference when deciding whether and how an app can deploy to Prisma Compute.
|
||||
|
||||
## CLI-First Model
|
||||
|
||||
Treat `@prisma/cli app deploy` as the deployment surface. Treat `create-prisma` as a new-project scaffold that can generate useful defaults and, for some templates, a `compute:deploy` script.
|
||||
|
||||
Compute deploy supports these framework keys:
|
||||
|
||||
```text
|
||||
nextjs
|
||||
nuxt
|
||||
astro
|
||||
hono
|
||||
nestjs
|
||||
tanstack-start
|
||||
custom
|
||||
bun
|
||||
```
|
||||
|
||||
Auto-detection:
|
||||
|
||||
- Next.js: `next.config.*` or `next` dependency
|
||||
- Nuxt: `nuxt.config.*` or `nuxt` dependency
|
||||
- Astro: `astro.config.*` or `astro` dependency
|
||||
- Hono: `hono` dependency
|
||||
- NestJS: `nest-cli.json` or `@nestjs/core` dependency
|
||||
- TanStack Start: `@tanstack/react-start` or `@tanstack/solid-start`
|
||||
- Custom artifact: explicit `framework: "custom"` plus `build.outputDirectory` and `build.entrypoint` in `prisma.compute.ts`
|
||||
- Bun: explicit `--entry <path>` or `--framework bun`
|
||||
|
||||
If detection is ambiguous, set `framework` in `prisma.compute.ts` or pass a supported `--framework` value. If the app is a source-level plain server, use `framework: "bun"` plus `entry`, or pass `--framework bun --entry <path>`, after verifying the server entrypoint. If the app already produces a runnable Node artifact, use `framework: "custom"` with `build.outputDirectory` and `build.entrypoint`.
|
||||
|
||||
## CLI Matrix
|
||||
|
||||
| App shape | Deploy command shape | Auto-detected | Required output/entry | Notes |
|
||||
|-----------|----------------------|---------------|-----------------------|-------|
|
||||
| Next.js | `--framework nextjs` | Yes | standalone `server.js` output | Requires `output: "standalone"` |
|
||||
| Nuxt | `--framework nuxt` | Yes | `.output/server/index.mjs` | Framework strategy supplies build defaults; a config `build` block is optional |
|
||||
| Astro | `--framework astro` | Yes | standalone Node server artifact | Framework strategy supplies build defaults; a config `build` block is optional |
|
||||
| Hono | `--framework hono` | Yes | Bun entry from `main`, `module`, `--entry`, or `src/index.ts` | Usually fixed port `8080` in generated config/scripts |
|
||||
| NestJS | `--framework nestjs` | Yes | NestJS server artifact | Omit host or bind to `0.0.0.0`; a config `build` block is optional |
|
||||
| TanStack Start | `--framework tanstack-start` | Yes | `.output/server/index.mjs` | Requires Nitro node output |
|
||||
| Custom artifact | config-backed `framework: "custom"` | No | configured `build.outputDirectory` and `build.entrypoint` | Use for prebuilt/custom-built Node artifacts |
|
||||
| Bun / plain server | `--framework bun --entry <path>` | With explicit entry | server entrypoint | Use for Elysia and custom HTTP servers |
|
||||
| Elysia | `--framework bun --entry src/index.ts` | No dedicated deploy key | Bun entrypoint | Preserve port/host handling |
|
||||
| SvelteKit | No deploy framework key | No | Node adapter/prebuilt artifact | Do not deploy `vite preview` |
|
||||
| Turborepo | Deploy concrete app targets | No | app-specific entry/output | Prefer `prisma.compute.ts` with `apps` |
|
||||
|
||||
`app build --build-type` uses the framework build type. Build types include `auto`, `nextjs`, `nuxt`, `astro`, `nestjs`, `tanstack-start`, `custom`, and `bun`.
|
||||
|
||||
`app run --build-type` is local-dev oriented and supports `auto`, `bun`, and `nextjs`. It streams the local dev server and is not proof that the deployed app is reachable through public ingress.
|
||||
|
||||
`prisma.compute.ts` can set framework, entrypoint, HTTP port, env inputs, app root, region, and build settings. A config `build` block is accepted for every supported framework; all build types are config-backed (`nextjs`, `nuxt`, `astro`, `nestjs`, `tanstack-start`, `custom`, `bun`; `hono` builds through the `bun` strategy). For Nuxt, Astro, and NestJS the framework strategy supplies the default build command and output, so a `build` block is optional and normally unnecessary, but it overrides those defaults when present. Only `custom` requires one.
|
||||
|
||||
Config snippets below assume:
|
||||
|
||||
```typescript
|
||||
import { defineComputeConfig } from "@prisma/compute-sdk/config";
|
||||
```
|
||||
|
||||
## Universal Runtime Requirements
|
||||
|
||||
Compute needs a server process:
|
||||
|
||||
- It must listen on the deployed HTTP port. `@prisma/cli app deploy` defaults to the framework's default HTTP port (3000 for most frameworks, 4321 for Astro) unless `--http-port` is passed.
|
||||
- It must bind on all interfaces. Do not hard-code `localhost` or `127.0.0.1` for a deployed server; use `0.0.0.0`, `server.host: true`, or the framework equivalent.
|
||||
- It must have a deployable entrypoint or recognized framework output.
|
||||
- It must not rely on a preview-only command such as `vite preview`.
|
||||
- It must receive env vars through `--env`, project env, branch env, or external automation.
|
||||
|
||||
Check host and port together. A listener on the right port but bound to loopback can appear ready while public ingress cannot reach it.
|
||||
|
||||
## Next.js
|
||||
|
||||
Deploy shape:
|
||||
|
||||
```bash
|
||||
bunx @prisma/cli@latest app deploy --framework nextjs --env .env
|
||||
```
|
||||
|
||||
`next.config.ts` must include standalone output:
|
||||
|
||||
```typescript
|
||||
import type { NextConfig } from "next"
|
||||
|
||||
const nextConfig: NextConfig = {
|
||||
output: "standalone",
|
||||
}
|
||||
|
||||
export default nextConfig
|
||||
```
|
||||
|
||||
Do not pass `--entry` with `nextjs`; the CLI derives the runtime entrypoint from framework build output.
|
||||
|
||||
Do not set `HOSTNAME=localhost` or `HOSTNAME=127.0.0.1` in deploy env. If the standalone server host is overridden, use `0.0.0.0`.
|
||||
|
||||
## Hono
|
||||
|
||||
Deploy shape:
|
||||
|
||||
```bash
|
||||
bunx @prisma/cli@latest app deploy \
|
||||
--framework hono \
|
||||
--http-port 8080 \
|
||||
--env .env
|
||||
```
|
||||
|
||||
Config shape:
|
||||
|
||||
```typescript
|
||||
export default defineComputeConfig({
|
||||
app: {
|
||||
framework: "hono",
|
||||
entry: "src/index.ts",
|
||||
httpPort: 8080,
|
||||
env: ".env",
|
||||
},
|
||||
});
|
||||
```
|
||||
|
||||
Project expectations:
|
||||
|
||||
- `package.json` has `main` or `module` pointing at the entrypoint, or deploy passes `--entry src/index.ts`
|
||||
- server uses `@hono/node-server`
|
||||
- code reads `process.env.PORT` and defaults to the same port used by `--http-port`
|
||||
- code does not set `hostname` to `localhost` or `127.0.0.1`; if hostname is set explicitly, use `0.0.0.0`
|
||||
|
||||
Example runtime shape:
|
||||
|
||||
```typescript
|
||||
const rawPort = (process.env.PORT ?? "").trim()
|
||||
const parsedPort = rawPort.length > 0 ? Number(rawPort) : Number.NaN
|
||||
const port = Number.isInteger(parsedPort) ? parsedPort : 8080
|
||||
serve({ fetch: app.fetch, port })
|
||||
```
|
||||
|
||||
## NestJS
|
||||
|
||||
Deploy shape:
|
||||
|
||||
```bash
|
||||
bunx @prisma/cli@latest app deploy --framework nestjs --env .env
|
||||
```
|
||||
|
||||
Config shape:
|
||||
|
||||
```typescript
|
||||
export default defineComputeConfig({
|
||||
app: {
|
||||
framework: "nestjs",
|
||||
env: ".env",
|
||||
},
|
||||
});
|
||||
```
|
||||
|
||||
Project expectations:
|
||||
|
||||
- detection uses `nest-cli.json` or the `@nestjs/core` dependency; pass `--framework nestjs` when neither signal is present
|
||||
- `src/main.ts` or the compiled runtime must start an HTTP server
|
||||
- read `process.env.PORT` and default to the same port used by `--http-port`
|
||||
- omit the host argument in `app.listen(port)` or pass `"0.0.0.0"`; do not pass `"localhost"` or `"127.0.0.1"`
|
||||
- use `app build --build-type nestjs` for a Compute artifact check; `app run --build-type nestjs` is not supported, so use the Nest dev server locally
|
||||
|
||||
Example runtime shape:
|
||||
|
||||
```typescript
|
||||
const port = Number(process.env.PORT ?? "3000")
|
||||
await app.listen(port)
|
||||
```
|
||||
|
||||
## TanStack Start
|
||||
|
||||
Deploy shape:
|
||||
|
||||
```bash
|
||||
bunx @prisma/cli@latest app deploy --framework tanstack-start --env .env
|
||||
```
|
||||
|
||||
Expected `vite.config.ts` shape:
|
||||
|
||||
```typescript
|
||||
import { defineConfig } from "vite"
|
||||
import viteReact from "@vitejs/plugin-react"
|
||||
import { tanstackStart } from "@tanstack/react-start/plugin/vite"
|
||||
import { nitro } from "nitro/vite"
|
||||
|
||||
export default defineConfig({
|
||||
plugins: [tanstackStart(), nitro(), viteReact()],
|
||||
})
|
||||
```
|
||||
|
||||
Preserve these details:
|
||||
|
||||
- keep `nitro` in `dependencies`
|
||||
- keep `import { nitro } from "nitro/vite"`
|
||||
- keep `nitro()` in the Vite plugin list
|
||||
- keep the React Vite plugin after `tanstackStart()`
|
||||
- keep Nitro on its default node server preset; do not switch to edge, static, Cloudflare, or another non-Node preset for Compute
|
||||
|
||||
The build command is `vite build`. The build must produce `.output/server/index.mjs`, and the production start shape is:
|
||||
|
||||
```json
|
||||
{
|
||||
"scripts": {
|
||||
"build": "vite build",
|
||||
"start": "node .output/server/index.mjs"
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
Do not deploy TanStack Start as a Bun entrypoint such as `src/router.tsx`. If `.output/server/index.mjs` is missing, fix the TanStack/Nitro build path.
|
||||
|
||||
Make sure Nitro does not bind only to localhost in deployment. If host env/config is customized, use the framework's all-interface host setting rather than `localhost`.
|
||||
|
||||
## Nuxt
|
||||
|
||||
Deploy shape:
|
||||
|
||||
```bash
|
||||
bunx @prisma/cli@latest app deploy --framework nuxt --env .env
|
||||
```
|
||||
|
||||
Config shape:
|
||||
|
||||
```typescript
|
||||
export default defineComputeConfig({
|
||||
app: {
|
||||
framework: "nuxt",
|
||||
env: ".env",
|
||||
},
|
||||
});
|
||||
```
|
||||
|
||||
Nuxt uses Nitro output at `.output/server/index.mjs`. Keep the Nitro preset compatible with a Node server runtime.
|
||||
|
||||
## Astro
|
||||
|
||||
Deploy shape:
|
||||
|
||||
```bash
|
||||
bunx @prisma/cli@latest app deploy --framework astro --env .env
|
||||
```
|
||||
|
||||
Config shape:
|
||||
|
||||
```typescript
|
||||
export default defineComputeConfig({
|
||||
app: {
|
||||
framework: "astro",
|
||||
httpPort: 4321,
|
||||
env: ".env",
|
||||
},
|
||||
});
|
||||
```
|
||||
|
||||
Astro Compute-style server output usually needs:
|
||||
|
||||
```javascript
|
||||
import { defineConfig } from "astro/config"
|
||||
import node from "@astrojs/node"
|
||||
|
||||
export default defineConfig({
|
||||
output: "server",
|
||||
adapter: node({ mode: "standalone" }),
|
||||
server: { host: true },
|
||||
})
|
||||
```
|
||||
|
||||
## Bun, Elysia, and Plain Source Servers
|
||||
|
||||
Use the Bun deploy key for app shapes without a dedicated `--framework` value:
|
||||
|
||||
```bash
|
||||
bunx @prisma/cli@latest app deploy \
|
||||
--framework bun \
|
||||
--entry src/index.ts \
|
||||
--http-port 8080 \
|
||||
--env .env
|
||||
```
|
||||
|
||||
`app deploy` also treats `--entry <path>` without `--framework` as a Bun app deploy.
|
||||
|
||||
Requirements:
|
||||
|
||||
- pass `--entry` unless `package.json` `main` or `module` points at the runtime entrypoint
|
||||
- ensure the entrypoint starts an HTTP server, not only exports handlers
|
||||
- read `process.env.PORT` or align `--http-port` with the fixed listener port
|
||||
- bind on all interfaces
|
||||
|
||||
Elysia example:
|
||||
|
||||
```typescript
|
||||
const port = Number(process.env.PORT ?? "8080")
|
||||
app.listen({ port, hostname: "0.0.0.0" })
|
||||
```
|
||||
|
||||
## Custom Build Artifacts
|
||||
|
||||
Use `framework: "custom"` when the app is already built, or when a custom command produces a runnable Node artifact that Compute should stage as-is:
|
||||
|
||||
```typescript
|
||||
export default defineComputeConfig({
|
||||
app: {
|
||||
framework: "custom",
|
||||
build: {
|
||||
command: "npm run build",
|
||||
outputDirectory: "build",
|
||||
entrypoint: "handler.js",
|
||||
},
|
||||
httpPort: 3000,
|
||||
env: ".env",
|
||||
},
|
||||
});
|
||||
```
|
||||
|
||||
Requirements:
|
||||
|
||||
- set both `build.outputDirectory` and `build.entrypoint`
|
||||
- make `build.entrypoint` relative to `build.outputDirectory`
|
||||
- ensure the artifact starts an HTTP server and binds on all interfaces
|
||||
- use `command: null` only when the output directory already contains the deployable artifact
|
||||
|
||||
## SvelteKit and Other Frameworks
|
||||
|
||||
`@prisma/cli app deploy --framework` has no `svelte` framework key. Do not claim SvelteKit is directly deployable with that name.
|
||||
|
||||
For frameworks without a dedicated deploy key, use one of these paths:
|
||||
|
||||
- produce a Node server artifact and deploy with config-backed `framework: "custom"`, or through a supported prebuilt/SDK flow
|
||||
- if the app has a plain Node/Bun server entrypoint, deploy that entrypoint through `--framework bun --entry <path>`
|
||||
|
||||
SvelteKit should use a Node adapter or another production server artifact. Do not use `vite preview` as the deployed runtime.
|
||||
|
||||
## Turborepo
|
||||
|
||||
Deploy concrete app packages, not the monorepo root by default. Prefer `prisma.compute.ts` at the repo root with one `apps` entry per deploy target.
|
||||
|
||||
Checklist:
|
||||
|
||||
- choose the app directory, such as `apps/api`
|
||||
- run the workspace build from the correct root/package
|
||||
- pass the app package's runtime entrypoint or framework
|
||||
- pass the correct env file, which may live outside the app package
|
||||
- keep branch env/database scope aligned with the deployed app
|
||||
|
||||
Example config:
|
||||
|
||||
```typescript
|
||||
export default defineComputeConfig({
|
||||
apps: {
|
||||
web: { root: "apps/web", framework: "nextjs" },
|
||||
api: {
|
||||
root: "apps/api",
|
||||
framework: "bun",
|
||||
entry: "src/index.ts",
|
||||
httpPort: 3000,
|
||||
env: "packages/db/.env",
|
||||
},
|
||||
},
|
||||
});
|
||||
```
|
||||
|
||||
Deploy one target:
|
||||
|
||||
```bash
|
||||
bunx @prisma/cli@latest app deploy api --branch feature/foo --json
|
||||
```
|
||||
|
||||
Flag-only shape after confirming output paths:
|
||||
|
||||
```bash
|
||||
bun run build
|
||||
bunx @prisma/cli@latest app deploy \
|
||||
--framework bun \
|
||||
--entry apps/api/dist/src/index.js \
|
||||
--http-port 3000 \
|
||||
--env packages/db/.env
|
||||
```
|
||||
|
||||
Verify the actual output path before using this command.
|
||||
@@ -0,0 +1,167 @@
|
||||
# SDK and API Automation
|
||||
|
||||
Use this reference when building automation rather than using `create-prisma` or `@prisma/cli app deploy`.
|
||||
|
||||
## Prefer the CLI for App Workflows
|
||||
|
||||
For normal app deployment:
|
||||
|
||||
1. Use generated `compute:deploy` when present.
|
||||
2. Otherwise use `@prisma/cli app build/run/deploy`.
|
||||
3. Use SDK/API only for custom automation, platform integrations, or tool builders.
|
||||
|
||||
## Compute SDK
|
||||
|
||||
Install:
|
||||
|
||||
```bash
|
||||
npm install @prisma/compute-sdk @prisma/management-api-sdk
|
||||
```
|
||||
|
||||
Config helper:
|
||||
|
||||
```typescript
|
||||
import { defineComputeConfig } from "@prisma/compute-sdk/config";
|
||||
```
|
||||
|
||||
Use this import in `prisma.compute.ts` for type checking. The helper is an identity function; the CLI loader aliases the import when it evaluates config files, so a user project does not need the SDK solely to load a Compute config.
|
||||
|
||||
Create an authenticated Management API client:
|
||||
|
||||
```typescript
|
||||
import { createManagementApiClient } from "@prisma/management-api-sdk"
|
||||
|
||||
const apiClient = createManagementApiClient({
|
||||
token: process.env.PRISMA_API_TOKEN,
|
||||
})
|
||||
```
|
||||
|
||||
Token naming differs by surface. `@prisma/cli app ...` uses `PRISMA_SERVICE_TOKEN` for non-interactive service-token auth. The SDK examples here use `PRISMA_API_TOKEN` as an application convention for passing a token into `createManagementApiClient`; the SDK itself only receives the `token` string.
|
||||
|
||||
Deploy a prebuilt artifact:
|
||||
|
||||
```typescript
|
||||
import { ComputeClient, PreBuilt } from "@prisma/compute-sdk"
|
||||
|
||||
const compute = new ComputeClient(apiClient)
|
||||
const databaseUrl = process.env.DATABASE_URL
|
||||
if (!databaseUrl) throw new Error("DATABASE_URL is required")
|
||||
|
||||
const result = await compute.deploy({
|
||||
strategy: new PreBuilt({
|
||||
appPath: "./dist",
|
||||
entrypoint: "index.js",
|
||||
}),
|
||||
projectId: "proj_abc",
|
||||
appName: "my-app",
|
||||
// region: "us-east-1", // optional: explicit placement for a new app
|
||||
envVars: { DATABASE_URL: databaseUrl },
|
||||
portMapping: { http: 3000 },
|
||||
})
|
||||
|
||||
if (result.isOk()) {
|
||||
console.log(result.value.deploymentEndpointDomain)
|
||||
} else {
|
||||
console.error(result.error.message)
|
||||
}
|
||||
```
|
||||
|
||||
SDK methods return `Result<T, E>`. Check `isOk()` or `isErr()` instead of assuming errors throw. Deploy results expose app/deployment vocabulary including `appId`, `appName`, `projectId`, `region`, `deploymentId`, `deploymentEndpointDomain`, `appEndpointDomain`, `promoted`, `previousDeploymentId`, `previousDeploymentAction`, and `resolvedConfig`.
|
||||
|
||||
## SDK Build Strategies
|
||||
|
||||
Project Compute SDK strategies:
|
||||
|
||||
- `AutoBuild`: tries supported framework strategies such as Next.js, Nuxt, Astro, NestJS, TanStack Start, then Bun
|
||||
- `NextjsBuild`: requires standalone output and returns `server.js`
|
||||
- `NuxtBuild`: expects `.output/server/index.mjs`
|
||||
- `AstroBuild`: expects `dist/server/entry.mjs`
|
||||
- `NestjsBuild`: builds a NestJS HTTP server artifact
|
||||
- `TanstackStartBuild`: runs `vite build` and expects a Nitro node server at `.output/server/index.mjs`; keep `tanstackStart()` and `nitro()` in Vite config
|
||||
- `CustomBuild`: runs optional configured build settings and stages a configured artifact entrypoint
|
||||
- `BunBuild`: runs `bun build` and needs an explicit entrypoint or `package.json` `main`
|
||||
- `PreBuilt`: uses an existing artifact directory and relative entrypoint
|
||||
|
||||
## Regions
|
||||
|
||||
Known SDK region ids:
|
||||
|
||||
```text
|
||||
us-east-1
|
||||
us-west-1
|
||||
eu-west-3
|
||||
eu-central-1
|
||||
ap-northeast-1
|
||||
ap-southeast-1
|
||||
```
|
||||
|
||||
Use `--region` in `@prisma/cli app deploy` or `region` in SDK deploy input only when creating a new Compute app. Existing apps keep their current region.
|
||||
|
||||
`region` is optional on `deploy` and `createApp`. Omit it to use the Project/platform default when creating an app; do not hard-code a region unless placement is an application requirement.
|
||||
|
||||
## Repository-snapshot detection
|
||||
|
||||
Tooling that already has an in-memory repository tree can detect a deployable app without checking files out:
|
||||
|
||||
```typescript
|
||||
import { detectComputeApp } from '@prisma/compute-sdk/config'
|
||||
|
||||
const detected = detectComputeApp({
|
||||
root: 'apps/api',
|
||||
manifest: {
|
||||
main: 'src/index.ts',
|
||||
scripts: { start: 'bun src/index.ts' },
|
||||
dependencies: { hono: '^4' },
|
||||
},
|
||||
filePaths: ['apps/api/package.json', 'apps/api/src/index.ts'],
|
||||
})
|
||||
```
|
||||
|
||||
The result contains `framework`, `frameworkName`, `buildType`, `httpPort`, `entrypoint`, and detection `evidence`, or `null` when nothing is deployable. Paths are repository-relative and unsafe absolute/parent-traversal entrypoints are rejected.
|
||||
|
||||
The helper detects one app root. A monorepo consumer must enumerate workspaces and call it once per candidate. Detection reads `dependencies` and `devDependencies` (not peer dependencies), recognizes config files and framework packages, and can infer Bun-backed servers from valid `start`/`serve` script entrypoints.
|
||||
|
||||
## Management API Concepts
|
||||
|
||||
Compute resources map roughly to:
|
||||
|
||||
- Project: parent container
|
||||
- Branch: production or preview scope for env resolution and database/env attachment
|
||||
- App: stable app endpoint and branch attachment
|
||||
- Deployment: build artifact plus runtime status and preview URL
|
||||
|
||||
Low-level public routes use App/Deployment names:
|
||||
|
||||
- list/create apps under a project with `/v1/apps`
|
||||
- get/update/delete an app
|
||||
- create/list deployments for an app
|
||||
- get/start/stop/delete deployments with `/v1/deployments/:deploymentId`
|
||||
- promote or roll back an app using `deploymentId`
|
||||
- stream logs with `/v1/deployments/:deploymentId/logs`
|
||||
- manage custom domains
|
||||
|
||||
Internal compatibility aliases may still appear in code. Prefer App/Deployment names in new docs, skills, and automation.
|
||||
|
||||
Environment variables are not embedded directly in the low-level deployment create payload. The attached branch's role selects their scope: a preview branch resolves branch-scoped vars, while a production branch (or no branch) resolves project-scoped production vars. Use project/environment-variable APIs or CLI env commands to write env vars first, and keep the branch name consistent across app creation, database creation, and env writes.
|
||||
|
||||
When using the CLI alongside SDK automation:
|
||||
|
||||
```bash
|
||||
bunx @prisma/cli@latest project env add --file .env.preview --branch feature/foo
|
||||
bunx @prisma/cli@latest database create preview-db --branch feature/foo --json
|
||||
bunx @prisma/cli@latest app deploy --branch feature/foo --json --no-interactive
|
||||
```
|
||||
|
||||
Production promotion is not just "the same branch with another label"; `app promote <deployment-id>` rebuilds with production env vars.
|
||||
|
||||
## Secrets and Redaction
|
||||
|
||||
Management API deployment inspection exposes env var names with redacted values. Treat any value like `[redacted]` as a marker, not as the deployed value.
|
||||
|
||||
Do not log:
|
||||
|
||||
- service tokens
|
||||
- OAuth tokens
|
||||
- full database URLs
|
||||
- env var values
|
||||
- pre-signed upload URLs
|
||||
@@ -0,0 +1,454 @@
|
||||
# Troubleshooting Prisma Compute
|
||||
|
||||
Use this reference when setup, build, deploy, env, or runtime behavior fails.
|
||||
|
||||
## First Checks
|
||||
|
||||
Run:
|
||||
|
||||
```bash
|
||||
bunx @prisma/cli@latest --help
|
||||
bunx @prisma/cli@latest app deploy --help
|
||||
bunx @prisma/cli@latest auth whoami
|
||||
bunx @prisma/cli@latest auth workspace list --json
|
||||
```
|
||||
|
||||
Then inspect:
|
||||
|
||||
```bash
|
||||
pwd
|
||||
cat package.json
|
||||
find .. -maxdepth 3 \( -name 'prisma.compute.ts' -o -name 'prisma.compute.mts' -o -name 'prisma.compute.js' -o -name 'prisma.compute.mjs' -o -name 'prisma.compute.cjs' \) -print
|
||||
test -f .env && sed -n 's/=.*/=<redacted>/p' .env
|
||||
```
|
||||
|
||||
Do not print unredacted secrets.
|
||||
|
||||
## `prisma.compute.ts` Not Picked Up
|
||||
|
||||
This only matters when the project is supposed to use a config-backed deploy. A simple app without `prisma.compute.ts` can still deploy with explicit `app deploy` flags.
|
||||
|
||||
Symptoms:
|
||||
|
||||
- deploy ignores the expected framework, entrypoint, port, env file, or app root
|
||||
- a monorepo target such as `api` is not recognized
|
||||
- local state appears in the wrong `.prisma/` directory
|
||||
|
||||
Check:
|
||||
|
||||
```bash
|
||||
pwd
|
||||
find .. -maxdepth 4 \( -name 'prisma.compute.ts' -o -name 'prisma.compute.mts' -o -name 'prisma.compute.js' -o -name 'prisma.compute.mjs' -o -name 'prisma.compute.cjs' \) -print
|
||||
bunx @prisma/cli@latest app deploy --help
|
||||
```
|
||||
|
||||
Fix:
|
||||
|
||||
- keep exactly one compute config file in the directory where it lives
|
||||
- put repo-wide or monorepo config at the repository/workspace root
|
||||
- run commands from inside the repo or workspace boundary so discovery can walk up to the config
|
||||
- use `[app]` targets from the `apps` keys, such as `bunx @prisma/cli@latest app deploy api`
|
||||
- remember that config-relative paths such as `root` and `env.file` resolve from the config file directory
|
||||
|
||||
## Compute Config Invalid
|
||||
|
||||
Symptoms:
|
||||
|
||||
- `COMPUTE_CONFIG_INVALID`
|
||||
- `COMPUTE_CONFIG_TARGET_REQUIRED`
|
||||
- `COMPUTE_CONFIG_TARGET_UNKNOWN`
|
||||
- "Multiple compute config files found"
|
||||
|
||||
Fix:
|
||||
|
||||
- export `defineComputeConfig({ app: ... })` or `defineComputeConfig({ apps: ... })`
|
||||
- define exactly one of `app` or `apps`
|
||||
- remove unknown top-level keys
|
||||
- pass a target for multi-app build/run commands, such as `app build web`
|
||||
- pass an existing `apps` key for multi-app deploys, such as `app deploy api`
|
||||
- for `nuxt`, `astro`, and `nestjs`, prefer strategy defaults unless a custom `build` override is intentional; current configs allow the override
|
||||
- for `framework: "custom"`, set both `build.outputDirectory` and `build.entrypoint`
|
||||
- when `build.outputDirectory` is set for a configurable framework, also set `build.entrypoint` if the framework needs a configured runtime entrypoint
|
||||
|
||||
Minimal recovery config:
|
||||
|
||||
```typescript
|
||||
import { defineComputeConfig } from "@prisma/compute-sdk/config";
|
||||
|
||||
export default defineComputeConfig({
|
||||
app: {
|
||||
framework: "hono",
|
||||
entry: "src/index.ts",
|
||||
httpPort: 8080,
|
||||
},
|
||||
});
|
||||
```
|
||||
|
||||
## `create-prisma --yes` Did Not Deploy
|
||||
|
||||
`--yes` skips prompts and does not opt into deploy. Pass `--deploy` explicitly:
|
||||
|
||||
```bash
|
||||
bunx create-prisma@latest --name my-api --template hono --provider postgresql --deploy
|
||||
```
|
||||
|
||||
If the integrated deploy cannot complete, scaffold succeeds but deploy should be reported as failed.
|
||||
|
||||
## Accidental Prisma Postgres Provisioning
|
||||
|
||||
With PostgreSQL, no `--database-url`, and no `--no-prisma-postgres`, setup can provision Prisma Postgres. For local smoke tests, pass:
|
||||
|
||||
```bash
|
||||
--no-prisma-postgres --database-url "postgresql://USER:PASSWORD@HOST:PORT/DB"
|
||||
```
|
||||
|
||||
Use a disposable real database URL if Prisma commands need to run.
|
||||
|
||||
## Auth Fails
|
||||
|
||||
Symptoms:
|
||||
|
||||
- `project list` fails
|
||||
- `auth whoami` fails
|
||||
- browser login was not completed
|
||||
- commands use the wrong workspace after a second login
|
||||
- another workspace is stored locally but commands behave signed out
|
||||
- `PRISMA_SERVICE_TOKEN` is missing, empty, expired, or lacks workspace/project permissions
|
||||
|
||||
Fix:
|
||||
|
||||
```bash
|
||||
bunx @prisma/cli@latest auth login
|
||||
bunx @prisma/cli@latest auth whoami
|
||||
bunx @prisma/cli@latest auth workspace list --json
|
||||
```
|
||||
|
||||
If multiple local OAuth workspaces exist, switch explicitly. Prefer ids from JSON:
|
||||
|
||||
```bash
|
||||
bunx @prisma/cli@latest auth workspace use <workspace-id>
|
||||
bunx @prisma/cli@latest auth whoami --json
|
||||
bunx @prisma/cli@latest project list --json
|
||||
```
|
||||
|
||||
For a human terminal, `auth workspace use` with no argument opens an interactive picker or selects the only local OAuth workspace without prompting. In non-interactive or `--json` mode, use `auth workspace use <id-or-name>` instead.
|
||||
|
||||
If the active workspace was logged out or its token refresh failed, the CLI intentionally stays signed out for OAuth commands rather than falling through to another cached workspace. Recover by running `auth workspace list --json` and then `auth workspace use <workspace-id>`.
|
||||
|
||||
To remove only one local OAuth workspace session:
|
||||
|
||||
```bash
|
||||
bunx @prisma/cli@latest auth workspace logout <workspace-id-or-name>
|
||||
# or:
|
||||
bunx @prisma/cli@latest auth logout --workspace <workspace-id-or-name>
|
||||
```
|
||||
|
||||
Use plain `auth logout` only when you want to clear all local OAuth workspace sessions.
|
||||
|
||||
For CI, `@prisma/cli` can authenticate with `PRISMA_SERVICE_TOKEN`:
|
||||
|
||||
```bash
|
||||
test -n "${PRISMA_SERVICE_TOKEN:-}" && echo "PRISMA_SERVICE_TOKEN is set"
|
||||
bunx @prisma/cli@latest auth whoami
|
||||
bunx @prisma/cli@latest app deploy --json --no-interactive --prod --yes --env .env
|
||||
```
|
||||
|
||||
If `PRISMA_SERVICE_TOKEN` is set and non-empty, it is the active auth source and local OAuth workspace switching is unavailable for command execution. Unset `PRISMA_SERVICE_TOKEN` before using `auth workspace use` to change local OAuth workspace context.
|
||||
|
||||
If `PRISMA_SERVICE_TOKEN` is set but empty, the CLI errors before trying browser-login credentials. Unset it or provide a valid workspace service token. Never echo, log, or paste the token value; only check whether it is present.
|
||||
|
||||
Local storage hints for debugging:
|
||||
|
||||
- Override auth storage with `PRISMA_COMPUTE_AUTH_FILE` when isolating tests.
|
||||
- Default macOS OAuth credential file: `~/Library/Application Support/prisma/auth.json`.
|
||||
- Active workspace metadata sidecar: `~/Library/Application Support/prisma/auth.context.json`.
|
||||
- Project binding: `.prisma/local.json`.
|
||||
- Local app/project state: `.prisma/cli/state.json`, usually next to the discovered `prisma.compute.ts`.
|
||||
|
||||
Do not print credential files or token values into logs.
|
||||
|
||||
## Project Setup Fails
|
||||
|
||||
Symptoms:
|
||||
|
||||
- `PROJECT_SETUP_REQUIRED`
|
||||
- non-interactive deploy cannot choose a Project
|
||||
- deploy was expected to create a Project but did not
|
||||
|
||||
Fix:
|
||||
|
||||
```bash
|
||||
bunx @prisma/cli@latest app deploy --project <id-or-name> --json --no-interactive
|
||||
bunx @prisma/cli@latest app deploy --create-project <name> --yes
|
||||
```
|
||||
|
||||
Do not rely on `--yes` alone to choose Project scope. `--project`, `--create-project`, and `PRISMA_PROJECT_ID` are mutually exclusive.
|
||||
|
||||
## Missing or Placeholder `DATABASE_URL`
|
||||
|
||||
Symptoms:
|
||||
|
||||
- Prisma Client throws `DATABASE_URL is required`
|
||||
- migration scripts fail immediately
|
||||
- deploy runs but app fails on database access
|
||||
|
||||
Fix:
|
||||
|
||||
1. Put a real production-ready `DATABASE_URL` in `.env` or project env.
|
||||
2. Run `prisma generate`.
|
||||
3. Run migrations with the project's `db:migrate` or production migration command.
|
||||
4. Redeploy with `--env .env` or project env configured.
|
||||
|
||||
If Prisma Client generation or runtime env loading is the concrete failure, then inspect Prisma-specific config:
|
||||
|
||||
```bash
|
||||
test -f prisma.config.ts && sed -n '1,160p' prisma.config.ts
|
||||
test -f prisma/schema.prisma && sed -n '1,220p' prisma/schema.prisma
|
||||
```
|
||||
|
||||
Never deploy `postgresql://USER:PASSWORD@HOST:PORT/DATABASE` placeholder values.
|
||||
|
||||
## Wrong Branch, Env, or Database
|
||||
|
||||
Symptoms:
|
||||
|
||||
- preview deploy reads production env
|
||||
- branch deploy cannot find `DATABASE_URL`
|
||||
- app is deployed to the expected branch but points at the wrong database
|
||||
- logs are inspected for the current app while the failing URL belongs to a different deployment id
|
||||
|
||||
Check:
|
||||
|
||||
```bash
|
||||
bunx @prisma/cli@latest project show --json
|
||||
bunx @prisma/cli@latest project env list --role production --json
|
||||
bunx @prisma/cli@latest project env list --role preview --json
|
||||
bunx @prisma/cli@latest project env list --branch feature/foo --json
|
||||
bunx @prisma/cli@latest app list-deploys --json
|
||||
bunx @prisma/cli@latest app logs --deployment <deployment-id> --json
|
||||
```
|
||||
|
||||
Fix:
|
||||
|
||||
- pass the same `--branch <git-name>` to `app deploy`, `database create`, and branch-specific `project env` commands
|
||||
- use `--role production` for production env and `--role preview` for preview-template env
|
||||
- capture the deployment id and URL from deploy JSON, then inspect logs with `app logs --deployment <deployment-id>`
|
||||
- `app show`, `app list-deploys`, and `app logs` do not filter by branch; capture and use the deployment id
|
||||
- treat `app promote <deployment-id>` as a production action because it rebuilds with production env vars
|
||||
- do not expect `prisma.compute.ts` to select Project, Branch, production, or database scope; it only supplies app deploy defaults
|
||||
|
||||
## Database Wiring or Schema Did Not Apply
|
||||
|
||||
Symptoms:
|
||||
|
||||
- deploy runs but the app cannot find `DATABASE_URL`
|
||||
- database env vars exist but the database is empty
|
||||
- a deploy-all run points multiple apps at the same branch database
|
||||
|
||||
Fix:
|
||||
|
||||
- read [`app-deploy-cli.md`](app-deploy-cli.md) `Database and Env` for the database/env guardrails
|
||||
- create and assign database env vars explicitly for the intended branch/app scope
|
||||
- run migrations, seed, or schema push yourself after database setup; Compute never applies schema changes for you
|
||||
- for multi-app deploy-all with app-specific database isolation, create and assign those database env vars explicitly before deploy
|
||||
|
||||
## Workspace plan limit reached
|
||||
|
||||
When the installed CLI returns `PLAN_LIMIT_REACHED`, treat it as a workspace plan restriction rather than a Compute or database outage.
|
||||
|
||||
For agent/CI handling, run the relevant database command with `--json` and branch on `error.code === "PLAN_LIMIT_REACHED"`. Read `error.meta.upgradeUrl`, `planName`, `workspaceId`, and `usageBlocked`; optional values may be `null`. This is a workspace plan restriction rather than a Compute/database outage. Use the canonical upgrade URL when returned or direct the user to Prisma Console. Do not retry as an outage or infer a plan limit from status codes or message text.
|
||||
|
||||
## Next.js Standalone Missing
|
||||
|
||||
Error shape:
|
||||
|
||||
```text
|
||||
Next.js build did not produce standalone output
|
||||
```
|
||||
|
||||
Fix `next.config.ts`:
|
||||
|
||||
```typescript
|
||||
const nextConfig = {
|
||||
output: "standalone",
|
||||
}
|
||||
|
||||
export default nextConfig
|
||||
```
|
||||
|
||||
Then reinstall/build if needed and deploy again.
|
||||
|
||||
## Next.js dependency missing after a successful build
|
||||
|
||||
Symptoms in pnpm/Bun isolated workspaces can include a deployment that builds successfully but exits before useful runtime logs, often with `Cannot find module` for `styled-jsx` or another traced dependency.
|
||||
|
||||
The current Compute SDK preserves in-artifact package-store symlinks and materializes only safe out-of-tree targets when staging Next standalone output. Do not manually flatten or rewrite `.next/standalone/node_modules` symlinks; that can break the isolated-store layout.
|
||||
|
||||
Fix:
|
||||
|
||||
1. Upgrade `@prisma/compute-sdk` and `@prisma/cli` to current versions.
|
||||
2. Remove only the generated build artifact/cache appropriate to the project, then rebuild.
|
||||
3. Confirm `output: "standalone"`, redeploy, and inspect the new deployment logs.
|
||||
4. If it persists, report the package manager, workspace layout, first missing module, and SDK/CLI versions through `@prisma/cli feedback` without secrets.
|
||||
|
||||
## Nitro Entry Missing
|
||||
|
||||
Nuxt or TanStack Start error shape:
|
||||
|
||||
```text
|
||||
.output/server/index.mjs
|
||||
```
|
||||
|
||||
General fix:
|
||||
|
||||
- ensure the correct framework plugins are installed
|
||||
- run the framework build locally
|
||||
- avoid custom Nitro presets that produce a non-Node target
|
||||
- use the default Nitro node server preset
|
||||
|
||||
For TanStack Start specifically:
|
||||
|
||||
- keep `nitro` in `dependencies`
|
||||
- keep `import { nitro } from "nitro/vite"` in `vite.config.ts`
|
||||
- keep `plugins: [tanstackStart(), nitro(), viteReact()]` or the framework-equivalent plugin order
|
||||
- run `bun run build` and verify `.output/server/index.mjs` exists
|
||||
- do not replace the production server with `vite preview`
|
||||
|
||||
Compute detection selects TanStack Start when it sees `@tanstack/react-start` or `@tanstack/solid-start`. If the Nitro entrypoint is missing after that, fix the TanStack/Nitro build output; do not assume Compute will silently use a Bun deployment.
|
||||
|
||||
## Bun Entrypoint Missing
|
||||
|
||||
Error shape:
|
||||
|
||||
```text
|
||||
Entrypoint is required
|
||||
Entrypoint file does not exist
|
||||
```
|
||||
|
||||
Fix either:
|
||||
|
||||
```json
|
||||
{
|
||||
"main": "src/index.ts"
|
||||
}
|
||||
```
|
||||
|
||||
or deploy with:
|
||||
|
||||
```bash
|
||||
bunx @prisma/cli@latest app deploy --framework bun --entry src/index.ts
|
||||
```
|
||||
|
||||
## Port Mismatch
|
||||
|
||||
Symptoms:
|
||||
|
||||
- deploy succeeds but the app is unreachable
|
||||
- health checks fail
|
||||
- logs show the server listening on a different port
|
||||
|
||||
Fix:
|
||||
|
||||
- read `process.env.PORT`
|
||||
- pass `--http-port <port>` when the app has a fixed port
|
||||
- use the generated `compute:deploy` script when it exists
|
||||
- remember the `@prisma/cli app deploy` default is HTTP `3000`; generated Hono/Elysia projects usually configure `8080` through `prisma.compute.ts` or flag-backed `--http-port 8080` scripts
|
||||
- use the template defaults: Hono/Elysia `8080`, Next/TanStack/Nuxt `3000`, Astro `4321`
|
||||
|
||||
## Public URL Smoke Test Fails
|
||||
|
||||
Symptoms:
|
||||
|
||||
- deploy command completed
|
||||
- `app show` or deploy output has a URL
|
||||
- the public URL times out, returns 5xx, or returns an unexpected page
|
||||
|
||||
Check:
|
||||
|
||||
```bash
|
||||
curl -i https://<deployment-url>
|
||||
curl -i https://<deployment-url>/health
|
||||
bunx @prisma/cli@latest app logs --json
|
||||
```
|
||||
|
||||
Fix by following the first concrete failure:
|
||||
|
||||
- connection timeout or 5xx: check logs, host binding, and port mapping
|
||||
- unexpected status or body: verify the route path and app framework output
|
||||
- local URL tested by mistake: rerun against the public deployment URL, not `localhost` or `127.0.0.1`
|
||||
|
||||
## Localhost Binding
|
||||
|
||||
Symptoms:
|
||||
|
||||
- deploy says the app started or the port was observed, but the public URL is unreachable
|
||||
- logs show a server listening on `localhost` or `127.0.0.1`
|
||||
- `app run` works locally, but the deployed app cannot receive external traffic
|
||||
|
||||
Why this happens:
|
||||
|
||||
Compute's boot watcher polls `/proc/net/tcp` and `/proc/net/tcp6` for configured ports entering `LISTEN`. That readiness signal tracks the port, not whether the app bound `127.0.0.1` or all interfaces. A loopback-only listener can therefore look ready while public ingress still cannot reach it.
|
||||
|
||||
Fix:
|
||||
|
||||
- remove hard-coded `localhost` or `127.0.0.1` server host settings
|
||||
- bind on `0.0.0.0` or the framework equivalent, such as Astro `server.host: true`
|
||||
- for Next.js standalone, do not deploy with `HOSTNAME=localhost`; use `HOSTNAME=0.0.0.0` if the host is overridden
|
||||
- keep port and host fixes together: `0.0.0.0:<deployed-http-port>`
|
||||
|
||||
## Env Changes Did Not Apply
|
||||
|
||||
Generated `compute:deploy` scripts redeploy using the generated flags and/or `prisma.compute.ts`; they do not run migrations or seed data.
|
||||
|
||||
After env changes:
|
||||
|
||||
```bash
|
||||
bunx @prisma/cli@latest project env list
|
||||
bunx @prisma/cli@latest project env list --branch feature/foo
|
||||
bunx @prisma/cli@latest app deploy --prod --yes --env .env
|
||||
bunx @prisma/cli@latest app deploy --branch feature/foo --env .env.preview
|
||||
```
|
||||
|
||||
If using branch-specific env, confirm the branch name and role.
|
||||
|
||||
## Need Logs
|
||||
|
||||
Runtime logs for the current app:
|
||||
|
||||
```bash
|
||||
bunx @prisma/cli@latest app logs
|
||||
```
|
||||
|
||||
Specific deployment:
|
||||
|
||||
```bash
|
||||
bunx @prisma/cli@latest app logs --deployment <deployment-id>
|
||||
```
|
||||
|
||||
Machine-readable:
|
||||
|
||||
```bash
|
||||
bunx @prisma/cli@latest app logs --json
|
||||
```
|
||||
|
||||
Build logs for GitHub/Console builds:
|
||||
|
||||
```bash
|
||||
bunx @prisma/cli@latest build logs <build-id>
|
||||
bunx @prisma/cli@latest build logs <build-id> --follow
|
||||
bunx @prisma/cli@latest build logs <build-id> --json
|
||||
```
|
||||
|
||||
Use `build logs` for build output keyed by a Build id from a GitHub check run, Console build page, or Management API build record. Use `app logs` for runtime logs keyed by the current app deployment or a deployment id.
|
||||
|
||||
Summarize relevant errors. Do not paste secrets.
|
||||
|
||||
## Report Unresolved CLI Issues
|
||||
|
||||
When a CLI failure survives the checks above, or a command crashes with `UNEXPECTED_ERROR`, report it to the Prisma team:
|
||||
|
||||
```bash
|
||||
bunx @prisma/cli@latest feedback "app deploy crashed: <first error line>"
|
||||
```
|
||||
|
||||
Prefer the pre-filled command from a `--json` crash envelope's `nextActions` verbatim. Anonymous; never put secrets, connection URLs, or tokens in the message.
|
||||
Reference in New Issue
Block a user