Setting the file. One moment.
Subchapter 3.5
references/sdk-api.mdMarkdown7 KBView on GitHub
Use this reference when building automation rather than using create-prisma or @prisma/cli app deploy.
For normal app deployment:
compute:deploy when present.@prisma/cli app build/run/deploy.Install:
npm install @prisma/compute-sdk @prisma/management-api-sdkConfig helper:
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:
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:
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.
Project Compute SDK strategies:
AutoBuild: tries supported framework strategies such as Next.js, Nuxt, Astro, NestJS, TanStack Start, then BunNextjsBuild: requires standalone output and returns server.jsNuxtBuild: expects .output/server/index.mjsAstroBuild: expects dist/server/entry.mjsNestjsBuild: builds a NestJS HTTP server artifactTanstackStartBuild: runs vite build and expects a Nitro node server at .output/server/index.mjs; keep tanstackStart() and nitro() in Vite configCustomBuild: runs optional configured build settings and stages a configured artifact entrypointBunBuild: runs bun build and needs an explicit entrypoint or package.json mainPreBuilt: uses an existing artifact directory and relative entrypointKnown SDK region ids:
us-east-1
us-west-1
eu-west-3
eu-central-1
ap-northeast-1
ap-southeast-1Use --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.
Tooling that already has an in-memory repository tree can detect a deployable app without checking files out:
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.
Compute resources map roughly to:
Low-level public routes use App/Deployment names:
/v1/apps/v1/deployments/:deploymentIddeploymentId/v1/deployments/:deploymentId/logsInternal 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:
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-interactiveProduction promotion is not just “the same branch with another label”; app promote <deployment-id> rebuilds with production env vars.
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: