Prisma Compute
エージェントが Prisma Compute アプリの作成、デプロイ、運用、およびフレームワーク固有のデプロイ準備を行うためのガイド。
Prisma Compute CLI サーフェス
Compute アプリのワークフローには Prisma Platform CLI を使用します:
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
Compute アプリのデプロイには @prisma/cli@latest を使用します。新規プロジェクトのスキャフォールディングには create-prisma@latest を使用します。
フィードバックの送信と CLI 問題の報告
CLI にはビルトインのフィードバックチャンネルがあります。コマンドがクラッシュした場合（UNEXPECTED_ERROR）、トラブルシューティング後も失敗が続く場合、またはユーザーが Prisma チームにフィードバックを送信したい場合に使用してください:
bunx @prisma/cli@latest feedback "app deploy crashed: <first error line>"
bunx @prisma/cli@latest feedback "love the deploy flow" --email [email protected]
クラッシュ出力は、それ自体でここを指し示します。--json クラッシュエンベロープは、nextActions 内に recover エントリとして正確な事前入力済みコマンドを持ちます（そのまま実行します）。人間向けのクラッシュ出力は、Tell us what happened: というヒントで終わります。フィードバックは匿名であり、--email が渡されない限り、CLI バージョン、Node バージョン、OS プラットフォーム/アーキテクチャのみが添付されます。メッセージにシークレット、接続 URL、ユーザーデータを決して含めないでください。
信頼できる情報源の優先順位
編集または実行する内容を決定する際は、この順序で証拠を使用します:
- プロジェクトの生成されたスクリプトと設定、特に
prisma.compute.ts、compute:deploy、フレームワーク設定、package.json。 create-prismaおよび@prisma/cliからの CLI ヘルプ出力。- ローカルにインストールされたパッケージコード、生成されたアーティファクト、型定義。
- 公式ドキュメント。
適用タイミング
このスキルは以下に使用します:
- Prisma Compute にデプロイ可能な新しいアプリを作成する
- 既存の TypeScript アプリを Prisma Compute にデプロイする
- 型付けされた
prisma.compute.tsデプロイ設定を作成または更新する - フレームワークが Compute 対応かどうかを判断する
create-prisma --deploy、compute:deploy、またはapp deployをデバッグする- Compute アプリのログ、デプロイメント、環境変数、ドメインを管理し、プラットフォームブランチを一覧表示する（
branch list; ブランチの作成/削除コマンドはありません） - GitHub/Console ビルドログと GitHub push-to-deploy ステータスを検査する
- ブラウザ認証、複数の保存済みワークスペース、または Prisma サービス トークンを使用して非インタラクティブデプロイを実行する
@prisma/cliのローカル Prisma Platform ワークスペースを切り替え、選択、一覧表示、またはログアウトする@prisma/cli feedbackで解決不可能な Compute CLI の障害に関するフィードバックを送信する@prisma/compute-sdkまたは Management API 統合によるプログラムによるデプロイ
決定木
-
既存プロジェクトのデプロイまたは再デプロイ:
references/app-deploy-cli.mdを読んでください。 -
型付けされた Compute 設定、モノレポ、デプロイターゲット、アプケーションルート、ビルド/環境のデフォルト:
references/compute-config.mdを読んでください。 -
フレームワーク固有のビルド/ランタイム作業:
references/frameworks.mdを読んでください。 -
スキャフォールドからの新規プロジェクト:
references/create-prisma.mdを読んでください。 -
プログラムによるデプロイ、SDK、API、または低レベルのアプリ/デプロイメントの概念:
references/sdk-api.mdを読んでください。 -
ビルド、認証、環境、デプロイ、またはランタイムの失敗:
references/troubleshooting.mdを読んでください。
優先順位別ルール
| 優先度 | カテゴリ | 影響 | プレフィックス |
|---|---|---|---|
| 1 | コマンド検証 | CRITICAL | verify- |
| 2 | 認証とワークスペース選択 | CRITICAL | auth- |
| 3 | フレームワーク対応状況 | CRITICAL | framework- |
| 4 | ランタイムホストとポートバインディング | CRITICAL | runtime- |
| 5 | 型付けされた Compute 設定 | HIGH | config- |
| 6 | ブランチ、環境、データベースの配線 | HIGH | env- |
| 7 | デプロイ操作 | HIGH | deploy- |
| 8 | SDK と API 自動化 | MEDIUM | sdk- |
クイックルール
1. コマンド検証
verify-help-first- 作業中に CLI ヘルプ出力を使用してコマンド構文を確認します。verify-prisma-vs-platform-cli-prisma app deployが ORM CLI に存在すると想定しないでください。タスクが@prisma/cliを使用すべきかどうかを確認します。verify-generated-scripts- プロジェクトにすでにcompute:deployスクリプトがある場合は、それを優先します。verify-public-url- 実際のデプロイ後は、ローカルまたは準備完了のみのチェックを信頼するのではなく、公開デプロイメント URL を要求します。verify-config-support-prisma.compute.tsを型付けされた Compute 設定として扱います。編集またはデプロイする前に、プロジェクトの設定と生成されたスクリプトを検査します。verify-auth-workspace-support- ローカルワークスペースの一覧表示/使用/ログアウトフローには@prisma/cli auth workspaceコマンドを使用します。
2. 認証とワークスペース選択
auth-source-precedence- 空でないPRISMA_SERVICE_TOKENはアクティブな認証ソースであり、コマンド実行時にはローカル OAuth ワークスペースは無視されます。トークンが設定されているが空の場合、CLI は保存された OAuth にフォールバックせずに失敗する必要があります。auth-multi-workspace-auth loginは、同じマシン上の複数のワークスペースに対して OAuth セッションを保存できます。アクティブワークスペースポインタは、通常のコマンドがどの保存された OAuth 権限を使用するかを選択します。auth-list-before-switch-auth workspace list --jsonを使用してローカルセッションを検査します。エージェントは、名前があいまいになる可能性があるため、JSON からのワークスペース ID を優先する必要があります。auth-switch-explicitly- 非インタラクティブな切り替えにはauth workspace use <id-or-name>を使用します。引数なしのauth workspace useは、インタラクティブピッカーを使用するか、ローカル OAuth ワークスペースが1つだけの場合にのみ使用します。auth-no-fallthrough- アクティブな OAuth ワークスペースがログアウトまたはリフレッシュに失敗した場合、CLI は他のキャッシュされたワークスペースに静かにフォールスルーしてはいけません。auth workspace use <id>を実行して次のワークスペースを選択します。auth-single-workspace-logout-auth workspace logout <id-or-name>またはauth logout --workspace <id-or-name>を使用して、1つのローカル OAuth ワークスペースセッションを削除します。単純なauth logoutは、すべてのローカル OAuth ワークスペースセッションをクリアします。auth-service-token-switching-PRISMA_SERVICE_TOKENが設定されている間は、auth workspace useは使用できません。これはサービス トークンがアクティブな認証ソースだからです。環境変数を設定解除して、ローカル OAuth ワークスペースを切り替えます。ワークスペースのログアウトは、依然としてローカル OAuth 状態のみをクリーンアップします。auth-storage-awareness- ローカル OAuth 認証情報はプラットフォーム認証ファイルに保存され、ワークスペースメタデータはサイドカーコンテキストファイルに保存されます。プロジェクトのピンは.prisma/local.jsonに保存され、CLI アプリ/プロジェクトの状態は、prisma.compute.tsが存在する場合はその近くの.prisma/cli/state.jsonに保存されます。
3. フレームワーク対応状況
framework-cli-first-create-prismaがスキャフォールディングできるものではなく、@prisma/cli app deployに対してデプロイ準備態勢を評価します。framework-supported-cli-deploy- Compute デプロイは、nextjs、nuxt、astro、hono、nestjs、tanstack-start、custom、bunをサポートしています。framework-create-prisma-defaults-only-create-prismaは生成されたデフォルトとcompute:deployを提供できますが、既存のアプリの一般的なデプロイサーフェスではありません。framework-build-output- Compute には、サーバーエントリポイントまたはフレームワークアーティファクトが必要であり、静的出力のみでは不十分です。
4. ランタイムホストとポートバインディング
runtime-bind-all-interfaces- デプロイされたサーバーは、すべてのインターフェース（0.0.0.0またはフレームワークの同等のもの）にバインドする必要があり、ハードコードされたlocalhostや127.0.0.1ではいけません。runtime-match-http-port- アプリはデプロイされた HTTP ポートでリッスンする必要があります。可能な場合はprocess.env.PORTを読み取り、一致する--http-portを渡します。runtime-readiness-port-only- Compute の readiness はリッスン中のポートを監視します。ループバックのみのリスナーは準備完了のように見えるかもしれませんが、パブリックイングレスは到達できません。runtime-respond-within-60s- イングレスはアプリが応答を開始するまでに 60 秒を与え、その後504 Gateway Time-outを返してリクエストをキャンセルします。ハンドラーが最初に応答し、waitUntilまたはキューを使用してより長い処理を実行するように設計し、リクエスト内で決して実行しないでください。
5. 型付けされた Compute 設定
config-optional-simple-app- 通常の単一アプリをデプロイするためにprisma.compute.tsは必須ではありません。永続的な設定がない場合はフラグを使用します。config-init-formalizer-bunx @prisma/cli@latest initで新しい設定を生成します。これはフレームワークを検出し、名前/フレームワーク/httpPort（Bun/Hono のエントリも）を固定し、プロジェクトリンクを提供します。--format jsonは依存関係のないprisma.compute.jsonを代わりに書き込みます。initは設定がすでに存在する場合は拒否し、コードをスキャフォールディングせず、デプロイもしません。config-use-prisma-compute-ts- 再利用可能なデプロイデフォルトは、prisma.config.tsではなく、defineComputeConfigを使用してprisma.compute.tsに記述します。config-app-vs-apps- 単一のデプロイターゲットにはappを、モノレポまたはマルチアプリリポジトリにはappsを使用します。正確に1つを定義します。config-monorepo-roots- モノレポの場合、prisma.compute.tsを使用してアプリターゲット、ルート、フレームワークデフォルト、エントリポイント、ポート、環境入力を宣言します。config-targets- マルチアプリ設定では、@prisma/cli app deploy webはapps.webターゲットを選択します。[app]がない場合、コマンドは現在のディレクトリからターゲットを推測できます。それ以外の場合、deploy はすべてのターゲットで実行できますが、build/run は1つを必要とします。config-region-new-app-only- 設定のregionは、新しく作成されたアプリのデフォルトにすぎません。既存のアプリへのデプロイは、アプリの現在のリージョンを維持します。config-custom-artifact- プリビルドまたはカスタムビルドされたアーティファクトには、build.outputDirectoryとbuild.entrypointを指定してframework: "custom"を使用します。config-no-project-branch-secrets- ワークスペース、プロジェクト、ブランチ、本番環境の意図、サービス トークン、シークレット値をprisma.compute.tsにコミットしないでください。これらはフラグ、.prisma/local.json、環境変数ストレージ、または CI シークレットに保持します。region、root、framework、entry、httpPort、および非シークレットの env ファイルパスなどのアプリレベルのデフォルトは設定に属します。config-flags-win---framework、--entry、--http-port、--region、--envなどの明示的なデプロイフラグは、一致する設定値を上書きします。
6. ブランチ、環境、データベース
env-do-not-leak-secrets-DATABASE_URL、サービス トークン、またはシークレット値を完全な形で決して出力しないでください。env-deploy-loads-dotenv- 生成されたデプロイスクリプトは、prisma.compute.tsまたは--env .envを介して env をロードする場合があります。再デプロイする前に実際のスクリプト/設定を検査します。env-migrations-separate- 再デプロイスクリプトはマイグレーションやシードデータを実行しません。適切な Prisma データベーススクリプトを別途実行してください。env-cli-token-name-@prisma/cliはサービス トークン認証にPRISMA_SERVICE_TOKENを使用します。env-branch-scope- ブランチデプロイ、ブランチ環境変数、ブランチデータベースは同じブランチ名を使用する必要があります。プレビューブランチをターゲットにする場合は、--branch <git-name>を明示的に渡します。env-production-vs-preview- 本番環境には--role production、プレビューテンプレート環境には--role preview、ブランチ固有のオーバーライドには--branch <git-name>を使用します。env-db-explicit- データベースと環境の配線は、データベースおよびプロジェクト環境コマンドを介して明示的に保ちます。デプロイの例にはデータベースセットアップを含めず、デプロイはマイグレーション、シードデータ、またはアプリごとに1つのデータベースを自動的に作成しません。
7. デプロイ操作
deploy-prod-intent---prod --yesは、ユーザーが本番デプロイを意図している場合にのみ使用します。アプリの最初の本番デプロイは--prodなしで自動プロモートされます。このフラグは、後続のプロダクションブランチデプロイをゲートします。deploy-no-promote-app deploy --no-promoteをビルドしてから検証するために使用します。これにより、候補が独自の URL で到達可能になり、ライブデプロイメントには影響を与えず、後でapp promote <deployment-id>でプロモートされます。deploy-github-default-branch- Compute アプリが GitHub の push-to-deploy に接続されている場合、デフォルトブランチへのマージが本番デプロイパスになります。ユーザーにマージされた PR ブランチを再デプロイしたり、デフォルトブランチのプレビューデプロイを実行したりするように指示する代わりに、デプロイメントレコードまたは GitHub チェックの実行状況を確認します。deploy-build-logs- GitHub/Console のビルド出力には@prisma/cli build logs <build-id>を使用します。ランタイムデプロイメントログにはapp logsを使用します。2つの ID は異なります。deploy-noninteractive-auth- 非インタラクティブデプロイには、正しいアクティブな保存済み OAuth ワークスペース、またはサポートされているサービス トークン環境変数のいずれかが必要です。トークンを決して出力しないでください。deploy-json-for-agents- スクリプトおよびエージェントが読み取り可能な出力には--json --no-interactiveを使用します。deploy-create-project---create-project <name>は、ユーザーがデプロイで新しいプロジェクトを作成してリンクしたい場合にのみ使用します。--projectおよびPRISMA_PROJECT_IDと競合します。deploy-ops-targets- アプリの表示/開く/ログ/デプロイ一覧/プロモート/ロールバック/削除およびドメインコマンドも、prisma.compute.tsからの[app]ターゲットを受け入れることができます。deploy-report-cli-bugs-UNEXPECTED_ERRORまたは解決不可能な障害が発生した場合は、フィードバックコマンドで報告します。上記の「フィードバックの送信と CLI 問題の報告」を参照してください。
8. SDK と API
sdk-use-cli-first- アプリワークフローには@prisma/cli app deployを優先します。ユーザーがより低レベルの自動化を構築している場合を除き、create-prismaは新しいアプリをスキャフォールディングするためにのみ使用します。sdk-result-handling-@prisma/compute-sdkはResult値を返します。例外に依存する代わりに、isOk()/isErr()をチェックします。sdk-snapshot-detection- ディスクにチェックアウトされていないリポジトリスナップショットにはdetectComputeAppを使用します。ワークスペースを自分で列挙し、候補となるアプケーションルートごとに1回呼び出します。
推奨ワークフロー
- プロジェクトを検査します: パッケージマネージャー、テンプレート/フレームワーク、
package.jsonのスクリプト、Prisma バージョン、Prisma Client の場所、prisma.compute.ts、既存のcompute:deploy。 - 実際に使用されているパッケージの CLI ヘルプ出力を確認します。
- プロジェクト/アプリの変更の前に認証コンテキストを確認します:
auth whoami --json、および複数のローカルセッションが存在する可能性がある場合はauth workspace list --json。 - パスを選択します:
- 既存のアプリデプロイ: config バックアップのターゲット（存在する場合）、生成された
compute:deploy、または@prisma/cli app build/run/deployフラグ - 新規アプリスキャフォールド:
create-prisma、次に生成されたcompute:deployまたは@prisma/cli app deploy - 低レベル...
- 既存のアプリデプロイ: config バックアップのターゲット（存在する場合）、生成された