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 のプッシュ-to-デプロイステータスを検査する場合
- ブラウザ認証、複数の保存されたワークスペース、または Prisma サービス トークンを使用して非インタラクティブなデプロイを実行する場合
- ローカルの Prisma Platform ワークスペースを
@prisma/cli用に切り替え、選択、一覧表示、またはログアウトする場合 @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>を使用します。インタラクティブなピッカー用、またはローカル OAuth ワークスペースがちょうど 1 つ存在する場合にのみ、引数なしのauth workspace useを使用します。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-@prisma/cli app deployに対してデプロイ準備を評価します。create-prismaがスキャフォールディングできるものに対してではありません。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 の準備完了チェックはリッスン中のポートを監視します。ループバック専用のリスナーは、パブリックイングレスが到達できないのに準備完了に見えることがあります。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で新しい設定を生成します：フレームワークを検出し、name/framework/httpPort（Bun/Hono の場合はエントリも）をピン留めし、プロジェクトリンクを提供します。--format jsonは依存関係のないprisma.compute.jsonを書き込みます。initは設定が既に存在する場合は拒否し、コードをスキャフォールディングせず、デプロイもしません。config-use-prisma-compute-ts- 再利用可能なデプロイデフォルトはprisma.config.tsではなく、prisma.compute.tsとdefineComputeConfigに配置します。config-app-vs-apps- 単一のデプロイターゲットにはappを、モノレポまたはマルチアプリリポジトリにはappsを使用します。正確に 1 つを定義します。config-monorepo-roots- モノレポの場合、prisma.compute.tsを使用してアプリターゲット、ルート、フレームワークデフォルト、エントリポイント、ポート、環境入力を宣言します。config-targets- マルチアプリ設定では、@prisma/cli app deploy webはapps.webターゲットを選択します。[app]がない場合、コマンドはカレントディレクトリからターゲットを推測できます。そうでなければ、デプロイはすべてのターゲットを実行できますが、build/run は 1 つを必要とします。config-region-new-app-only- 設定のregionは新しく作成されたアプリのデフォルトにすぎません。既存のアプリへのデプロイは、アプリの現在のリージョンを保持します。config-custom-artifact- プリビルドまたはカスタムビルドのアーティファクトには、framework: "custom"とbuild.outputDirectoryおよびbuild.entrypointを使用します。config-no-project-branch-secrets- ワークスペース、プロジェクト、ブランチ、プロダクションインテント、サービス トークン、シークレット値をprisma.compute.tsにコミットしないでください。これらはフラグ、.prisma/local.json、環境ストレージ、または CI シークレットに保持します。region、root、framework、entry、httpPort、およびシークレット以外の環境ファイルパスなどのアプリレベルのデフォルトは設定に属します。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-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- データベースと環境の配線は、データベースおよびプロジェクト環境コマンドを通じて明示的に保ちます。デプロイの例にはデータベース設定を追加せず、デプロイはマイグレーションの実行、データのシード、またはアプリごとに自動的にデータベースを作成しません。
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 のプッシュ-to-デプロイに接続されている場合、デフォルトブランチへのマージがプロダクションデプロイパスです。ユーザーにマージされた 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- App show/open/logs/list-deploys/promote/rollback/remove およびドメインコマンドは、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 クライアントの場所、prisma.compute.ts、既存のcompute:deploy。 - 実際に使用されているパッケージの CLI ヘルプ出力を確認します。
- プロジェクト/アプリの変更前に認証コンテキストを確認します：
auth whoami --json、および複数のローカルセッションが存在する可能性がある場合はauth workspace list --json。 - パスを選択します：
- 既存のアプリデプロイ：設定が存在する場合は設定バックアップのターゲット、生成された
compute:deploy、または@prisma/cli app build/run/deployフラグ - 新しいアプリのスキャフォールド：
create-prisma、次に生成されたcompute:deployまたは@prisma/cli app deploy - 低レベルの自動化：
@prisma/compute-sdkまたは Management API
- 既存のアプリデプロイ：設定が存在する場合は設定バックアップのターゲット、生成された
- デプロイプロセスを監視します：デプロイが完了するのを待ち、ビルドログまたはデプロイメントログを確認します。
- デプロイされた URL を確認します：ビルド/テスト段階では
--json出力を使用し、実際のデプロイ後はパブリック URL を取得します。