# Getting started (/docs/compute/getting-started) > For the complete Prisma documentation index, see [llms.txt](https://www.prisma.io/docs/llms.txt). A markdown version of any docs page is available by appending `.md` to its URL. Deploy your first Prisma Compute app with the unified Prisma CLI, then connect GitHub to deploy on every push. Location: Compute > Getting started Get an app live on [Prisma Compute](https://www.prisma.io/docs/compute) with the unified Prisma CLI: sign in, deploy a [Prisma Composer](https://www.prisma.io/docs/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](https://www.prisma.io/docs/cli). > [!NOTE] > This guide uses the Prisma CLI, run as `npx prisma `. Deployments come from the [`deploy` command](https://www.prisma.io/docs/cli/deploy) for a [Prisma Composer](https://www.prisma.io/docs/composer) app, from a git push once you [set up deploy on push](https://www.prisma.io/docs/compute/deploy-on-push), or from the [Console](https://pris.ly/pdp). The CLI creates the project, connects GitHub, and inspects the results. ## Prerequisites [#prerequisites] * A JavaScript runtime. The commands below run with `npx` or `pnpm` on Node.js 22.18 or newer, or with `bunx` (Bun). * A [Prisma Data Platform account](https://pris.ly/pdp). * A [Prisma Composer](https://www.prisma.io/docs/composer) app. [Deploy your first app](https://www.prisma.io/docs/prisma-compute/deploy) 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 [#sign-in] Authenticate first. Every other command needs a session: #### bun ```bash bunx prisma auth login ``` #### pnpm ```bash pnpm prisma auth login ``` #### yarn ```bash yarn prisma auth login ``` #### npm ```bash npx 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](#automation-and-ci) instead. To check who you are signed in as, run `auth whoami`. > [!NOTE] > Next.js apps should set `output: "standalone"` in their Next.js config. > > ```ts title="next.config.ts" > export default { output: "standalone" }; > ``` ## Deploy [#deploy] `deploy` does not build for you, so build the app first, then deploy its root module: #### bun ```bash bun run build bunx prisma deploy module.ts ``` #### pnpm ```bash pnpm run build pnpm prisma deploy module.ts ``` #### yarn ```bash yarn build yarn prisma deploy module.ts ``` #### npm ```bash npm run build npx 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`](https://www.prisma.io/docs/cli/deploy). [Deploy your first app](https://www.prisma.io/docs/prisma-compute/deploy) walks through the whole flow. Each deploy produces a service **version**. List, inspect, and open your services: #### bun ```bash bunx prisma service list bunx prisma service show bunx prisma service open ``` #### pnpm ```bash pnpm prisma service list pnpm prisma service show pnpm prisma service open ``` #### yarn ```bash yarn prisma service list yarn prisma service show yarn prisma service open ``` #### npm ```bash npx prisma service list npx prisma service show npx prisma service open ``` `service show` prints the service and its live version. Read the version's logs with: #### bun ```bash bunx prisma service logs --follow ``` #### pnpm ```bash pnpm prisma service logs --follow ``` #### yarn ```bash yarn prisma service logs --follow ``` #### npm ```bash npx prisma service logs --follow ``` To learn how versions are promoted, rolled back, started, and stopped, see [Deployments](https://www.prisma.io/docs/compute/deployments). ## Link a project [#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. If you deployed from this directory, it is already linked. To work from another checkout, or with a project your team already deployed, link to it by name: #### bun ```bash bunx prisma project link my-app ``` #### pnpm ```bash pnpm prisma project link my-app ``` #### yarn ```bash yarn prisma project link my-app ``` #### npm ```bash npx 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: #### bun ```bash bunx prisma project show bunx prisma project list ``` #### pnpm ```bash pnpm prisma project show pnpm prisma project list ``` #### yarn ```bash yarn prisma project show yarn prisma project list ``` #### npm ```bash npx prisma project show npx prisma project list ``` `project show` tells you what this directory is linked to. `project list` shows the projects you can see. ## Deploy on push [#deploy-on-push] To deploy on every push, connect the project to your GitHub repository and add a deploy workflow. Connect first: #### bun ```bash bunx prisma git connect ``` #### pnpm ```bash pnpm prisma git connect ``` #### yarn ```bash yarn prisma git connect ``` #### npm ```bash npx 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](https://github.com/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](https://www.prisma.io/docs/compute/deploy-on-push#4-add-the-deploy-workflow). If you connect in the [Console](https://pris.ly/pdp) 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 [#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](https://www.prisma.io/docs/postgres) database in the project (`npx prisma postgres create my-db` prints its connection string once) and store the URL as an environment variable: #### bun ```bash bunx prisma project env add DATABASE_URL=postgres://... --role production bunx prisma project env add DATABASE_URL=postgres://... --role preview ``` #### pnpm ```bash pnpm prisma project env add DATABASE_URL=postgres://... --role production pnpm prisma project env add DATABASE_URL=postgres://... --role preview ``` #### yarn ```bash yarn prisma project env add DATABASE_URL=postgres://... --role production yarn prisma project env add DATABASE_URL=postgres://... --role preview ``` #### npm ```bash npx prisma project env add DATABASE_URL=postgres://... --role production npx prisma project env add DATABASE_URL=postgres://... --role preview ``` Values are write-only and resolve at deploy time. See [Environment variables](https://www.prisma.io/docs/compute/environment-variables) for details. ## Automation and CI [#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: #### bun ```bash bunx prisma auth whoami ``` #### pnpm ```bash pnpm prisma auth whoami ``` #### yarn ```bash yarn prisma auth whoami ``` #### npm ```bash npx 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: ```bash PRISMA_SERVICE_TOKEN=... npx prisma service show web \ --project my-app \ --json \ --no-interactive ``` ### Agent skills [#agent-skills] If a coding agent does your deploying, install the Prisma Compute agent skill into your repo: #### bun ```bash bunx skills add prisma/skills --skill prisma-compute ``` #### pnpm ```bash pnpm dlx skills add prisma/skills --skill prisma-compute ``` #### yarn ```bash yarn dlx skills add prisma/skills --skill prisma-compute ``` #### npm ```bash npx 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](https://www.prisma.io/docs/ai/tools/skills) for the full catalog. For a Composer app, also run [`npx prisma@latest init`](https://www.prisma.io/docs/cli/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](https://www.prisma.io/docs/cli/skills) manage. ### Structured output [#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 [#console] To browse and manage the same resources without the CLI, open the [Console](https://pris.ly/pdp). It shows projects, branches, services, deployments, integrations, and domains. ## Next steps [#next-steps] * [Deployments](https://www.prisma.io/docs/compute/deployments): inspect, promote, roll back, start, stop. * [Environment variables](https://www.prisma.io/docs/compute/environment-variables): production, preview, and per-branch overrides. * [Branching](https://www.prisma.io/docs/compute/branching): how branches isolate work and map to Git. ## Related pages - [`Alchemy`](https://www.prisma.io/docs/compute/alchemy): Provision Prisma Postgres and deploy applications to Prisma Compute in one TypeScript stack. - [`Branching`](https://www.prisma.io/docs/compute/branching): Branches are isolated environments that map to your Git branches, so preview work never touches production. - [`Deploy Button`](https://www.prisma.io/docs/compute/deploy-button): Add a Deploy with Prisma button that copies a public Composer repository and starts a Composer-managed deployment. - [`Deploy on push`](https://www.prisma.io/docs/compute/deploy-on-push): Graduate a Composer app from manual deploys to a Git workflow, with production deploys on push and an isolated preview environment per branch. - [`Deployments`](https://www.prisma.io/docs/compute/deployments): How deploys create service versions on Prisma Compute, and how to inspect, promote, roll back, start, and stop them.