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: <첫 번째 오류 줄>"
bunx @prisma/cli@latest feedback "배포 흐름이 좋아요" --email [email protected]
충돌 출력은 자체적으로 이에 대해 안내합니다: --json 충돌 봉투는 nextActions의 recover 항목에 정확한 사전 입력 명령어를 담고 있습니다(그대로 실행). 사람이 읽을 수 있는 충돌 출력은 무슨 일이 있었는지 알려주세요: 힌트로 끝납니다. --email이 전달되지 않으면 피드백은 익명이며 CLI 버전, 노드 버전, 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/콘솔 빌드 로그 및 GitHub 푸시-투-배포 상태 검사
- 브라우저 인증, 여러 저장된 워크스페이스 또는 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- ORM CLI에prisma app deploy가 있다고 가정하지 마세요. 작업에@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 워크스페이스가 정확히 하나만 있을 때만 사용하세요.auth-no-fallthrough- 활성 OAuth 워크스페이스가 로그아웃되었거나 새로 고침에 실패하면 CLI는 다른 캐시된 워크스페이스로 자동으로 넘어가지 않아야 합니다.auth workspace use <id>를 실행하여 다음 워크스페이스를 선택하세요.auth-single-workspace-logout- 하나의 로컬 OAuth 워크스페이스 세션을 제거하려면auth workspace logout <id-or-name>또는auth logout --workspace <id-or-name>을 사용하세요. 일반auth logout은 모든 로컬 OAuth 워크스페이스 세션을 지웁니다.auth-service-token-switching-PRISMA_SERVICE_TOKEN이 설정되어 있는 동안auth workspace use는 사용할 수 없습니다. 서비스 토큰이 활성 인증 소스이기 때문입니다. 로컬 OAuth 워크스페이스를 전환하려면 env var를 설정 해제하세요. 워크스페이스 로그아웃은 여전히 로컬 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 준비 상태는 수신 대기 포트를 감시합니다. 루프백 전용 리스너는 퍼블릭 인그레스가 연결할 수 없는 동안 준비된 것으로 보일 수 있습니다.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를 사용하세요. 정확히 하나를 정의하세요.config-monorepo-roots- 모노레포의 경우prisma.compute.ts를 사용하여 앱 대상, 루트, 프레임워크 기본값, 진입점, 포트 및 환경 입력을 선언하세요.config-targets- 다중 앱 구성에서@prisma/cli app deploy web은apps.web대상을 선택합니다.[app]이 없으면 명령어는 현재 디렉토리에서 대상을 유추할 수 있습니다. 그렇지 않으면 배포는 모든 대상을 실행할 수 있지만 빌드/실행에는 하나가 필요합니다.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및 비밀이 아닌 환경 파일 경로와 같은 앱 수준 기본값은 구성에 속합니다.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- 데이터베이스 및 프로젝트 env 명령어를 통해 데이터베이스와 환경 연결을 명시적으로 유지하세요. 배포 예제는 데이터베이스 설정을 추가하지 않아야 하며, 배포는 마이그레이션, 시드 데이터를 실행하거나 앱당 하나의 데이터베이스를 자동으로 생성하지 않습니다.
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 푸시-투-배포에 연결된 경우, 기본 브랜치로의 병합이 프로덕션 배포 경로입니다. 사용자에게 병합된 PR 브랜치를 재배포하거나 기본 브랜치 미리보기 배포를 실행하라고 말하는 대신 배포 레코드 또는 GitHub 검사 실행을 확인하세요.deploy-build-logs- GitHub/콘솔 빌드 출력에는@prisma/cli build logs <build-id>를 사용하세요. 런타임 배포 로그에는app logs를 사용하세요. 두 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을 사용하세요. 워크스페이스를 직접 열거하고 후보 앱 루트당 한 번씩 호출하세요.
선호 워크플로
- 프로젝트 검사: 패키지 관리자, 템플릿/프레임워크,
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를 통한 SDK/API 자동화
- 기존 앱 배포: 구성 기반 대상(있는 경우), 생성된
- 배포: 명령어가 성공하거나 명확한 오류 메시지가 반환될 때까지 관련 레퍼런스를 반복해서 적용하고, 해결할 수 없는 CLI 오류는
feedback을 사용하여 보고하세요.