Getting started

Get an app live on Prisma Compute with the unified Prisma CLI: sign in, deploy a Prisma Composer app, then connect GitHub so every push deploys. This guide takes you from your code to a live URL, then covers deploying on push, environment variables, CI, and agents. For every command and flag, see the CLI reference.

Prerequisites

• A JavaScript runtime. The commands below run with npx or pnpm on Node.js 22.18 or newer on the 22 line, 24.11 or newer on the 24 line, or 26 or newer, or with bunx (Bun).
• A Prisma Data Platform account.
• A Prisma Composer app. Deploy your first app shows how to declare a new app or one you already have. To deploy on push, the app also needs a GitHub repository you can connect.

Sign in

Authenticate first. Every other command needs a session:

bunx prisma auth login

This opens a browser to sign you in, then stores a session that every later command inherits. Because the browser step is interactive, CI and other headless environments use a service token instead. To check who you are signed in as, run auth whoami.

export default { output: "standalone" };

Deploy

deploy does not build for you, so build the app first, then deploy its root module:

bun run build
bunx prisma deploy module.ts

The first deploy creates a project named after the app your module exports, unless you override the name with --name. It provisions the app's services on Compute and any databases on Prisma Postgres, and prints each service's URL. A new project needs a region, so set one in your deploy config or as PRISMA_REGION before the first deploy; see deploy. Deploy your first app walks through the whole flow.

Each deploy produces a service version. List, inspect, and open your services:

bunx prisma service list
bunx prisma service show <service>
bunx prisma service open <service>

service show prints the service and its live version. Read the version's logs with:

bunx prisma service logs <service> --follow

To learn how versions are promoted, rolled back, started, and stopped, see Deployments.

Link a project

A project groups your services, branches, and databases. The service and git commands act on the project this directory is linked to. deploy creates the project but does not link the directory to it; only project link and project create do. Link this directory, another checkout, or a project your team already deployed by name:

bunx prisma project link my-app

Linking writes the selected project to .prisma/local.json. This file is gitignored and only stores your local link, so it should not be treated as committed configuration. To verify the link, run:

bunx prisma project show
bunx prisma project list

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

Deploy on push

To deploy on every push, connect the project to your GitHub repository and add a deploy workflow. Connect first:

bunx prisma git connect

This starts the GitHub App install flow if needed and links the repository. The connection lets the repository's GitHub Actions runs sign in to your workspace, but it does not deploy anything. Pushes are deployed by a workflow that runs prisma/cloud-deploy-action: on each push it installs dependencies, runs your build, and runs the same deploy command. Add the workflow file as shown in Deploy on push. If you connect in the Console instead of the CLI, it opens a pull request that adds the workflow for you.

Once the workflow is committed, every push deploys: the default Git branch deploys to production, and every other branch gets its own isolated preview named after it. Follow each run in the repository's Actions tab.

Environment variables

Set environment variables per scope, production or preview, before the deploy that should use them. To connect a database, create a Prisma Postgres database in the project (npx prisma postgres create my-db prints its connection string once) and store the URL as an environment variable:

bunx prisma project env add DATABASE_URL=postgres://... --role production
bunx prisma project env add DATABASE_URL=postgres://... --role preview

Values are write-only and resolve at deploy time. See Environment variables for details.

Automation and CI

The same commands run unattended in CI or under a coding agent.

If you have 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 auth whoami

For CI, or any environment where the browser sign-in is not an option, authenticate with a service token instead. Set PRISMA_SERVICE_TOKEN and the CLI uses it before any stored session. Pass targets explicitly so nothing depends on a prompt. Add --json for structured output, and --no-interactive so the CLI fails instead of asking:

PRISMA_SERVICE_TOKEN=... npx prisma service show web \
  --project my-app \
  --json \
  --no-interactive

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 workflow (auth, config, deploys, logs, and domains), so it follows the right steps. Supported agents pick it up automatically. See Agent Skills for the full catalog. For a Composer app, also run npx prisma@latest init once. It syncs the Composer skill that ships inside @prisma/composer and keeps it matching the installed version; that package-shipped set is what the CLI's own skills commands manage.

Structured output

In --json mode, every command emits an envelope with an ok flag. On failure, error.code is a dotted NAMESPACE.SUBCODE (for example SERVICE.PROJECT_SETUP_REQUIRED), error.summary and error.why explain the problem, and nextActions lists concrete follow-up commands. Scripts and agents should branch on the code rather than the message: codes are a stable contract, while wording can change between releases.

Console

To browse and manage the same resources without the CLI, open the Console. It shows projects, branches, services, deployments, integrations, and domains.

Next steps

• Deployments: inspect, promote, roll back, start, stop.
• Environment variables: production, preview, and per-branch overrides.
• Branching: how branches isolate work and map to Git.