@prisma/cli

Deploy an app to Prisma Compute in two commands: sign in, then app deploy. This guide takes you from your code to a live URL, then covers the variations you'll need next. For every command, flag, and error code, see the CLI reference.

Install nothing up front: run the @prisma/cli beta package directly with npx. The package installs an executable called prisma-cli.

Prerequisites

• A JavaScript runtime. The commands below run with npx or pnpm on Node.js 22.12 or newer, or with bunx (Bun).
• A Prisma Data Platform account.
• An app directory to deploy.

Sign in

Deploys fail without a session, so authenticate first:

bunx @prisma/cli@latest auth login

This opens a browser to sign you in, then stores a session that every later command inherits, including any coding agent working in your directory. The browser step needs a human; in CI or other headless environments, use a service token instead. To check who you're signed in as, run auth whoami.

Deploy your app

From your app directory, run:

bunx @prisma/cli@latest app deploy

Then the CLI sets up the project, builds your app, and deploys it. After it finishes, you get a live URL.

To stream the app's logs:

bunx @prisma/cli@latest app logs

To open the live URL in your browser:

bunx @prisma/cli@latest app open

That is the core deploy loop. The sections below cover variations on it.

A shorter command

The binary is prisma-cli, not prisma. That's deliberate: many projects already have the prisma binary from Prisma ORM, and the beta package doesn't shadow it.

To avoid typing npx @prisma/cli@latest each time, install the package and add your own script:

bun add --dev @prisma/cli

{
  "scripts": {
    "deploy": "prisma-cli app deploy"
  }
}

Now npm run deploy does the same thing.

Link an existing project

On your first deploy, the CLI creates a project for you. If your team already has one, link to it before you deploy instead:

bunx @prisma/cli@latest project link my-app

Either path writes .prisma/local.json, a gitignored file that pins this directory to a project. It's a local cache, not committed config. Two commands to check your wiring:

bunx @prisma/cli@latest project show
bunx @prisma/cli@latest project list

project show tells you what this directory is linked to; project list shows the projects you can see.

Pick a framework

The CLI detects your framework automatically. Today there is first-class support for Next.js, Nuxt, Astro, Hono, and TanStack Start:

bunx @prisma/cli@latest app deploy --framework nextjs
bunx @prisma/cli@latest app deploy --framework hono --entry src/index.ts
bunx @prisma/cli@latest app deploy --framework tanstack-start

Deploy a plain Bun server by pointing --entry at your server file:

bunx @prisma/cli@latest app deploy --framework bun --entry src/server.ts

export default { output: "standalone" };

Check it builds locally

Before you deploy, you can build and run the app on your machine:

bunx @prisma/cli@latest app build
bunx @prisma/cli@latest app run --port 3000

Deploy to production

Your first deployment is promoted to production automatically. After that, every production deploy needs an explicit --prod flag, so you don't ship to production by accident:

bunx @prisma/cli@latest app deploy --prod

Without --prod, a deploy that resolves to the production branch and already has a live production deployment fails with the error code PROD_DEPLOY_REQUIRES_FLAG. With --prod, the CLI shows the current live deployment and asks you to confirm before replacing it.

For scripts and CI, pass both --prod and -y / --yes to accept the confirmation up front:

bunx @prisma/cli@latest app deploy --prod --yes

In non-interactive mode, a --prod deploy without --yes can't prompt, so it fails with CONFIRMATION_REQUIRED; re-run with --prod --yes.

Preview deploys never need --prod and never ask for confirmation. To learn about promotion and rollback, see the Deployments docs.

Automation and CI

The CLI is built for agents and CI, not just terminals.

If you've already signed in with auth login, anything running in that environment inherits your session, including an agent working in your directory. Check the session:

bunx @prisma/cli@latest auth whoami

For CI, or any environment where the browser sign-in isn't an option, authenticate with a service token instead. Set PRISMA_SERVICE_TOKEN and the CLI uses it before any stored session:

PRISMA_SERVICE_TOKEN=... npx @prisma/cli@latest app deploy \
  --project my-app \
  --app web \
  --branch feature/search \
  --json \
  --no-interactive

Pass targets explicitly so nothing depends on a prompt. --json gives you structured output to parse; --no-interactive makes the CLI fail instead of asking. In non-interactive mode the CLI won't set up a project for you, so create it inline when you need a self-contained run:

bunx @prisma/cli@latest app deploy --create-project my-app --app web

Agent skills

If a coding agent does your deploying, install the Prisma Compute agent skill into your repo:

bunx skills add prisma/skills --skill prisma-compute

The prisma-compute skill teaches your agent the Compute deploy workflow (auth, framework detection, deploys, logs, and domains), so it follows the right steps. Supported agents pick it up automatically from .agents/skills/.

To install every Prisma skill (ORM CLI, Postgres, and more) at once, run npx skills add prisma/skills.

Structured output

In --json mode, every result is an envelope with an ok flag. On failure, error.code identifies the problem, error.fix says what to do about it, and nextSteps lists the exact commands to run next. Branch on the error code rather than the message: codes are a stable contract, while message wording can change between releases. The common ones:

For the full list, see the error codes reference.

Console

To view your resources instead of running commands, use the Console for projects, branches, apps, deployments, integrations, and domains. It shows them in a visual way and lets you manage them with buttons instead of commands.

Next steps

• CLI reference: every command, flag, and error code.
• Deployments: inspect, promote, roll back, remove.
• Environment variables: give your app a database connection string and other config.
• Branching: how branches isolate work and map to Git.
• GitHub integration: deploy on push.