Configuration

prisma.compute.ts is an optional, committed file that declares what you deploy. Builds already work with zero config (the platform detects your framework), so reach for a config file when you want one of these:

• Reproducible deploys. Pin the framework, port, and build settings so every deploy (yours, a teammate's, or deploy-on-push) does the same thing without re-passing flags.
• A monorepo. Declare several apps in one repository and deploy them together, or one at a time.
• Type safety. Catch a typo'd field or an invalid framework in your editor, before you deploy.

The file is read by platform builds and the service commands. It never selects your project, branch, or production; those stay explicit. It also does not configure a database; see Environment variables for the connection string.

A minimal config

Export a single app with defineComputeConfig:

import { defineComputeConfig } from "@prisma/compute-sdk/config";

export default defineComputeConfig({
  app: {
    framework: "hono",
    entry: "src/index.ts",
    httpPort: 8080,
  },
});

Every field is optional. An empty app: {} is valid and defers entirely to detection. The values you do set become the defaults for builds and the service commands; explicit flags still win over them.

bun add --dev @prisma/compute-sdk

App fields

Each app accepts these fields. All are optional.

import { defineComputeConfig } from "@prisma/compute-sdk/config";

export default defineComputeConfig({
  app: {
    name: "api",
    framework: "hono",
    entry: "src/index.ts",
    httpPort: 8080,
  },
});

Regions

region is one of us-east-1, us-west-1, eu-west-3, eu-central-1, ap-northeast-1, or ap-southeast-1. It applies only when a deploy creates the app; an app that already exists keeps its current region.

A top-level region (next to app or apps) sets the default for every app in the config; a per-app region overrides it.

Environment

env is either a dotenv file path, or an object with file path(s) and inline variables:

export default defineComputeConfig({
  app: {
    // Shorthand: a single dotenv file.
    env: ".env",
  },
});

export default defineComputeConfig({
  app: {
    env: {
      file: [".env", ".env.production"],
      vars: { LOG_LEVEL: "info" },
    },
  },
});

File paths resolve from the config file's directory. Any --env flag you pass on the command line replaces the config's env inputs entirely; they do not merge.

Build settings

A build block lets you own how an app is built:

export default defineComputeConfig({
  app: {
    framework: "nextjs",
    build: {
      command: "pnpm run build",
      outputDirectory: ".next/standalone",
    },
  },
});

• Every field is optional. A field you set overrides the framework default; a field you omit is inferred.
• command: null skips the build step entirely.
• entrypoint names the built artifact's entry file, relative to outputDirectory when one is set (otherwise to the app root). For hono and bun apps it's required whenever you set outputDirectory, and setting both entry and a differing build.entrypoint is a configuration error.
• A build block works with every framework. With the custom framework it's required, and must set both outputDirectory and entrypoint.

Without a build block, the CLI infers everything (running your package.json build script when there is one, otherwise the framework default) and shows you what it chose during the deploy.

Where the file lives

The CLI reads the nearest config file, searching from your current directory up to the repository or workspace root (the closest ancestor with a .git, pnpm-workspace.yaml, bun.lock, bun.lockb, or a workspaces field). Discovery never escapes the repository.

Per directory, exactly one of prisma.compute.ts, prisma.compute.mts, prisma.compute.js, prisma.compute.mjs, prisma.compute.cjs, or prisma.compute.json may exist.

The config file's directory is treated as the project directory: the .prisma/local.json project pin lives there, and paths in the config (root, env.file) resolve from there. That means the config means the same thing no matter which subdirectory you run the command from.

Monorepos

Use apps instead of app to declare several apps in one repository, keyed by a target name:

import { defineComputeConfig } from "@prisma/compute-sdk/config";

export default defineComputeConfig({
  apps: {
    api: {
      root: "apps/api",
      framework: "hono",
      entry: "src/index.ts",
    },
    web: {
      root: "apps/web",
      framework: "nextjs",
    },
  },
});

All the apps live in one project, deploying to the same branch. A push builds every declared app, fanned out into a targeted build per app. The service commands accept the target name as a positional (service show api) or resolve it from the directory you run them in (the deepest matching root wins).

How config and flags interact

Config values are defaults. Explicit flags always win: --service outranks the config's app name for service selection, and a command run with explicit selectors never depends on the file.

The config never sets your project, branch, or production target; those are always resolved the same way, from the directory's project link and your Git branch. A config that fails to load or validate stops the build before any remote work, with a clear message pointing at the field to fix.

What's next

• CLI reference: every command and flag.
• Deploy your first app: the end-to-end quickstart.
• Environment variables: scoped configuration, secrets, and your database connection string.
• GitHub integration: deploy-on-push, including monorepos.