Prisma Compute

Was macht Prisma Compute?

Leiten Sie Agents durch die Erstellung, Bereitstellung, Operationen und framework-spezifische Bereitstellungsbereitschaft von Prisma Compute Apps.

Prisma Compute CLI-Oberfläche

Verwenden Sie die Prisma Platform CLI für Compute App Workflows:

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

Verwenden Sie @prisma/cli@latest für die Bereitstellung von Compute Apps. Verwenden Sie create-prisma@latest für das Scaffolding neuer Projekte.

Feedback senden und CLI-Probleme melden

Die CLI verfügt über einen integrierten Feedback-Kanal. Verwenden Sie ihn immer dann, wenn ein Befehl abstürzt (UNEXPECTED_ERROR), ein Fehler nach der Fehlerbehebung bestehen bleibt oder der Benutzer darum bittet, Feedback an das Prisma-Team zu senden:

bunx @prisma/cli@latest feedback "app deploy crashed: <erste Fehlerzeile>"
bunx @prisma/cli@latest feedback "liebe den Deploy-Flow" --email [email protected]

Absturzausgaben verweisen hierauf selbstständig: --json-Absturzhüllen enthalten den genauen vorausgefüllten Befehl als recover-Eintrag in nextActions (führen Sie ihn unverändert aus), und menschliche Absturzausgaben enden mit einem Hinweis Tell us what happened:. Feedback ist anonym, es sei denn, --email wird übergeben, und fügt nur die CLI-Version, Node-Version und OS-Plattform/Architektur bei. Fügen Sie niemals Geheimnisse, Verbindungs-URLs oder Benutzerdaten in die Nachricht ein.

Reihenfolge der verlässlichen Quellen

Verwenden Sie bei der Entscheidung, was bearbeitet oder ausgeführt werden soll, Beweise in dieser Reihenfolge:

1. Die generierten Skripte und Konfigurationen des Projekts, insbesondere prisma.compute.ts, compute:deploy, Framework-Konfiguration und package.json.
2. CLI-Hilfeausgabe von create-prisma und @prisma/cli.
3. Lokaler installierter Paketcode, generierte Artefakte und Typdefinitionen.
4. Offizielle Dokumentation.

Wann anzuwenden

Verwenden Sie dieses Skill für:

• Erstellen einer neuen App, die auf Prisma Compute bereitgestellt werden kann
• Bereitstellen einer bestehenden TypeScript-App auf Prisma Compute
• Erstellen oder Aktualisieren einer typisierten prisma.compute.ts-Deploy-Konfiguration
• Entscheiden, ob ein Framework Compute-bereit ist
• Debuggen von create-prisma --deploy, compute:deploy oder app deploy
• Verwalten von Compute-App-Logs, Deployments, Umgebungsvariablen und Domains sowie Auflisten von Platform-Branches (branch list; es gibt keine Branch-Erstellungs-/Entfernungsbefehle)
• Überprüfen von GitHub/Console-Build-Logs und des GitHub Push-to-Deploy-Status
• Durchführen von nicht-interaktiven Deployments mit Browser-Auth, mehreren gespeicherten Workspaces oder Prisma Service-Tokens
• Wechseln, Auswählen, Auflisten oder Abmelden lokaler Prisma Platform Workspaces für @prisma/cli
• Senden von Feedback zu einem nicht behebbaren Compute-CLI-Fehler mit @prisma/cli feedback
• Programmgesteuerte Deployments mit @prisma/compute-sdk oder Management-API-Integrationen

Entscheidungsbaum

1. Bereitstellung oder erneute Bereitstellung eines bestehenden Projekts: Lesen Sie references/app-deploy-cli.md.

2. Typisierte Compute-Konfiguration, Monorepos, Deploy-Ziele, App-Roots oder Build-/Env-Standardwerte: Lesen Sie references/compute-config.md.

3. Framework-spezifische Build-/Laufzeitarbeit: Lesen Sie references/frameworks.md.

4. Neues Projekt aus einem Scaffold: Lesen Sie references/create-prisma.md.

5. Programmgesteuerte Bereitstellung, SDKs, APIs oder Low-Level-App-/Deployment-Konzepte: Lesen Sie references/sdk-api.md.

6. Build-, Auth-, Env-, Deploy- oder Laufzeitfehler: Lesen Sie references/troubleshooting.md.

Regeln nach Priorität

Priorität	Kategorie	Auswirkung	Präfix
1	Befehl-Überprüfung	KRITISCH	verify-
2	Auth und Workspace-Auswahl	KRITISCH	auth-
3	Framework-Bereitschaft	KRITISCH	framework-
4	Runtime-Host- und Port-Bindung	KRITISCH	runtime-
5	Typisierte Compute-Konfiguration	HOCH	config-
6	Branch-, Umgebungs- und Datenbankverkabelung	HOCH	env-
7	Deploy-Operationen	HOCH	deploy-
8	SDK- und API-Automatisierung	MITTEL	sdk-

Kurzregeln

1. Befehl-Überprüfung

• verify-help-first - Verwenden Sie die CLI-Hilfeausgabe, um die Befehlssyntax während der Arbeit zu bestätigen.
• verify-prisma-vs-platform-cli - Gehen Sie nicht davon aus, dass prisma app deploy in der ORM-CLI existiert; prüfen Sie, ob die Aufgabe @prisma/cli verwenden soll.
• verify-generated-scripts - Bevorzugen Sie das generierte Skript compute:deploy, wenn ein Projekt bereits eines besitzt.
• verify-public-url - Fordern Sie nach einem echten Deploy die öffentliche Deployment-URL an, anstatt sich auf lokale oder reine Bereitschaftsprüfungen zu verlassen.
• verify-config-support - Behandeln Sie prisma.compute.ts als die typisierte Compute-Konfiguration; überprüfen Sie die Konfiguration und generierten Skripte des Projekts, bevor Sie Änderungen vornehmen oder bereitstellen.
• verify-auth-workspace-support - Verwenden Sie @prisma/cli auth workspace-Befehle für lokale Workspace-Listen-/Verwenden-/Abmelden-Abläufe.

2. Auth und Workspace-Auswahl

• auth-source-precedence - Ein nicht leerer PRISMA_SERVICE_TOKEN ist die aktive Auth-Quelle für Befehle, und lokale OAuth-Workspaces werden für die Ausführung ignoriert. Falls gesetzt, aber leer, sollte die CLI fehlschlagen, anstatt auf gespeichertes OAuth zurückzugreifen.
• auth-multi-workspace - auth login kann OAuth-Sitzungen für mehrere Workspaces auf demselben Rechner speichern. Der aktive Workspace-Zeiger wählt aus, welches gespeicherte OAuth-Grant normale Befehle verwenden.
• auth-list-before-switch - Verwenden Sie auth workspace list --json, um lokale Sitzungen zu überprüfen. Agents sollten Workspace-IDs aus JSON gegenüber Namen bevorzugen, da Namen mehrdeutig sein können.
• auth-switch-explicitly - Verwenden Sie auth workspace use <id-or-name> für nicht-interaktives Wechseln. Verwenden Sie auth workspace use ohne Argument nur für einen interaktiven Auswahldialog oder wenn genau ein lokaler OAuth-Workspace existiert.
• auth-no-fallthrough - Falls der aktive OAuth-Workspace abgemeldet ist oder die Aktualisierung fehlschlägt, sollte die CLI nicht stillschweigend auf einen anderen zwischengespeicherten Workspace zurückfallen. Führen Sie auth workspace use <id> aus, um den nächsten Workspace auszuwählen.
• auth-single-workspace-logout - Verwenden Sie auth workspace logout <id-or-name> oder auth logout --workspace <id-or-name>, um eine lokale OAuth-Workspace-Sitzung zu entfernen. Ein einfaches auth logout löscht alle lokalen OAuth-Workspace-Sitzungen.
• auth-service-token-switching - Während PRISMA_SERVICE_TOKEN gesetzt ist, ist auth workspace use nicht verfügbar, da der Service-Token die aktive Auth-Quelle ist; setzen Sie die Umgebungsvariable zurück, um lokale OAuth-Workspaces zu wechseln. Das Abmelden von Workspaces bereinigt weiterhin nur den lokalen OAuth-Zustand.
• auth-storage-awareness - Lokale OAuth-Anmeldeinformationen befinden sich in der Platform-Auth-Datei, mit Workspace-Metadaten in einer Sidecar-Kontextdatei. Projekt-Pins befinden sich in .prisma/local.json, und der CLI-App/Projekt-Zustand befindet sich in .prisma/cli/state.json in der Nähe von prisma.compute.ts, sofern vorhanden.

3. Framework-Bereitschaft

• framework-cli-first - Bewerten Sie die Deploy-Bereitschaft gegenüber @prisma/cli app deploy, nicht gegenüber dem, was create-prisma scafolden kann.
• framework-supported-cli-deploy - Compute Deploy unterstützt nextjs, nuxt, astro, hono, nestjs, tanstack-start, custom und bun.
• framework-create-prisma-defaults-only - create-prisma kann generierte Standardwerte und compute:deploy bereitstellen, ist aber nicht die allgemeine Deploy-Oberfläche für bestehende Apps.
• framework-build-output - Compute benötigt einen Server-Einstiegspunkt oder ein Framework-Artefakt, nicht nur statische Ausgabe.

4. Runtime-Host- und Port-Bindung

• runtime-bind-all-interfaces - Bereitgestellte Server müssen auf allen Schnittstellen (0.0.0.0 oder das Framework-Äquivalent) binden, nicht auf hartcodiertes localhost oder 127.0.0.1.
• runtime-match-http-port - Die App muss auf dem bereitgestellten HTTP-Port lauschen: lesen Sie process.env.PORT wenn möglich, oder übergeben Sie den passenden --http-port.
• runtime-readiness-port-only - Compute-Bereitschaft überwacht lauschende Ports; ein nur auf Loopback lauschender Listener kann bereit erscheinen, während das öffentliche Ingress ihn nicht erreichen kann.
• runtime-respond-within-60s - Das Ingress gibt einer App 60 Sekunden, um zu antworten, und gibt dann 504 Gateway Time-out zurück und bricht die Anfrage ab. Gestalten Sie Handler so, dass sie zuerst antworten und längere Arbeiten unter waitUntil oder aus einer Warteschlange ausführen, niemals innerhalb der Anfrage.

5. Typisierte Compute-Konfiguration

• config-optional-simple-app - prisma.compute.ts ist nicht erforderlich, um eine normale einzelne App bereitzustellen; verwenden Sie Flags, wenn keine dauerhafte Konfiguration vorhanden ist.
• config-init-formalizer - Generieren Sie eine neue Konfiguration mit bunx @prisma/cli@latest init: Es erkennt das Framework, legt Name/Framework/httpPort fest (plus Einstiegspunkt für Bun/Hono) und bietet den Projekt-Link an. --format json schreibt eine abhängigkeitsfreie prisma.compute.json stattdessen. init lehnt ab, wenn bereits eine Konfiguration existiert, scaffoldet niemals Code und stellt niemals bereit.
• config-use-prisma-compute-ts - Setzen Sie wiederverwendbare Deploy-Standardwerte in prisma.compute.ts mit defineComputeConfig, nicht in prisma.config.ts.
• config-app-vs-apps - Verwenden Sie app für ein einzelnes Deploy-Ziel und apps für Monorepos oder Multi-App-Repos; definieren Sie genau einen Eintrag.
• config-monorepo-roots - Verwenden Sie für Monorepos prisma.compute.ts, um App-Ziele, Roots, Framework-Standardwerte, Einstiegspunkte, Ports und Env-Eingaben zu deklarieren.
• config-targets - In Multi-App-Konfigurationen wählt @prisma/cli app deploy web das Ziel apps.web. Ohne [app] können Befehle das Ziel aus dem aktuellen Verzeichnis ableiten; andernfalls kann Deploy alle Ziele ausführen, während Build/Run ein Ziel erfordern.
• config-region-new-app-only - Eine Konfigurations-region ist nur ein Standardwert für neu erstellte Apps; Deployments auf bestehende Apps behalten die aktuelle Region der App bei.
• config-custom-artifact - Verwenden Sie framework: "custom" mit build.outputDirectory und build.entrypoint für vorgefertigte oder benutzerdefinierte Artefakte.
• config-no-project-branch-secrets - Committen Sie Workspace, Project, Branch, Produktionsabsicht, Service-Tokens oder geheime Werte nicht in prisma.compute.ts; bewahren Sie diese in Flags, .prisma/local.json, Env-Speicher oder CI-Geheimnissen auf. App-Level-Standardwerte wie region, root, framework, entry, httpPort und nicht geheime Env-Dateipfade gehören in die Konfiguration.
• config-flags-win - Explizite Deploy-Flags wie --framework, --entry, --http-port, --region und --env überschreiben entsprechende Konfigurationswerte.

6. Branch, Umgebung und Datenbank

• env-do-not-leak-secrets - Geben Sie niemals vollständige DATABASE_URL, Service-Tokens oder geheime Werte aus.
• env-deploy-loads-dotenv - Generierte Deploy-Skripte können Env über prisma.compute.ts oder --env .env laden; überprüfen Sie das tatsächliche Skript/die Konfiguration vor dem erneuten Deploy.
• env-migrations-separate - Redeploy-Skripte führen keine Migrationen oder Seed-Daten aus. Führen Sie die entsprechenden Prisma-Datenbankskripte separat aus.
• env-cli-token-name - @prisma/cli verwendet PRISMA_SERVICE_TOKEN für die Service-Token-Authentifizierung.
• env-branch-scope - Branch-Deployments, Branch-Umgebungsvariablen und Branch-Datenbanken müssen denselben Branch-Namen verwenden; übergeben Sie --branch <git-name> explizit, wenn Sie einen Preview-Branch anvisieren.
• env-production-vs-preview - Verwenden Sie --role production für die Produktionsumgebung, --role preview für die Preview-Vorlagenumgebung und --branch <git-name> für Branch-spezifische Überschreibungen.
• env-db-explicit - Halten Sie die Datenbank- und Env-Verkabelung explizit durch Datenbank- und Projekt-Env-Befehle; Deploy-Beispiele sollten keine Datenbankeinrichtung hinzufügen, und Deployments führen keine Migrationen, Seed-Daten aus oder erstellen automatisch eine Datenbank pro App.

7. Deploy-Operationen

• deploy-prod-intent - Verwenden Sie --prod --yes nur, wenn der Benutzer ein Produktions-Deploy beabsichtigt. Das erste Produktions-Deploy einer App wird ohne --prod automatisch befördert; das Flag schaltet nachfolgende Produktions-Branch-Deployments frei.
• deploy-no-promote - Verwenden Sie app deploy --no-promote für Build-and-Verify: Es erstellt einen Kandidaten, der unter seiner eigenen URL erreichbar ist, ohne das Live-Deployment zu berühren, der später mit app promote <deployment-id> befördert wird.
• deploy-github-default-branch - Wenn eine Compute-App mit GitHub Push-to-Deploy verbunden ist, ist ein Merge in den Default-Branch der Produktions-Deploy-Pfad; überprüfen Sie Deployment-Datensätze oder GitHub-Check-Runs, anstatt Benutzern zu sagen, sie sollen den gemergten PR-Branch erneut bereitstellen oder ein Default-Branch-Preview-Deploy ausführen.
• deploy-build-logs - Verwenden Sie @prisma/cli build logs <build-id> für GitHub/Console-Build-Ausgabe. Verwenden Sie app logs für Laufzeit-Deployment-Logs; die beiden IDs sind unterschiedlich.
• deploy-noninteractive-auth - Nicht-interaktive Deployments benötigen entweder den korrekten aktiven gespeicherten OAuth-Workspace oder eine unterstützte Service-Token-Umgebungsvariable; geben Sie den Token niemals aus.
• deploy-json-for-agents - Verwenden Sie --json --no-interactive für Skripte und agentenlesbare Ausgabe.
• deploy-create-project - Verwenden Sie --create-project <name> nur, wenn der Benutzer möchte, dass Deploy ein neues Projekt erstellt und verknüpft; es konfligiert mit --project und PRISMA_PROJECT_ID.
• deploy-ops-targets - App show/open/logs/list-deploys/promote/rollback/remove und Domain-Befehle können ebenfalls [app]-Ziele aus prisma.compute.ts akzeptieren.
• deploy-report-cli-bugs - Melden Sie bei UNEXPECTED_ERROR oder einem nicht behebbaren Fehler diesen mit dem Feedback-Befehl; siehe „Feedback senden und CLI-Probleme melden“ oben.

8. SDK und API

• sdk-use-cli-first - Bevorzugen Sie @prisma/cli app deploy für App-Workflows; verwenden Sie create-prisma nur zum Scaffolden einer neuen App, es sei denn, der Benutzer baut eine Automatisierung auf niedrigerer Ebene.
• sdk-result-handling - @prisma/compute-sdk gibt Result-Werte zurück; überprüfen Sie isOk()/isErr(), anstatt sich auf Ausnahmen zu verlassen.
• sdk-snapshot-detection - Verwenden Sie detectComputeApp für Repository-Snapshots, die nicht auf die Festplatte ausgecheckt sind; enumerieren Sie Workspaces selbst und rufen Sie es einmal pro Kandidaten-App-Root auf.

Bevorzugter Workflow

1. Überprüfen Sie das Projekt: Paketmanager, Template/Framework, package.json-Skripte, Prisma-Version, Prisma-Client-Speicherort, prisma.compute.ts und vorhandenes compute:deploy.
2. Überprüfen Sie die CLI-Hilfeausgabe für das tatsächlich verwendete Paket.
3. Überprüfen Sie den Auth-Kontext vor Projekt-/App-Mutationen: auth whoami --json, und wenn mehrere lokale Sitzungen existieren könnten, auth workspace list --json.
4. Wählen Sie den Pfad:
   • Vorhandenes App-Deploy: konfigurationsgestütztes Ziel, sofern vorhanden, generiertes compute:deploy oder @prisma/cli app build/run/deploy-Flags
   • Neues App-Scaffold: create-prisma, dann generiertes compute:deploy oder @prisma/cli app deploy
   • Low-Level-Automatisierung: @prisma/compute-sdk oder Management-API
5. Folgen Sie der Entscheidungsbaum und den Regeln nach Priorität.
6. Verweisen Sie bei spezifischen Konfigurations-, Framework-, SDK/API- oder Fehlerbehebungsdetails auf die Referenzdateien.

Referenzdateien

• App Deploy CLI
• Compute Config
• Frameworks
• Create Prisma
• SDK/API
• Fehlerbehebung