# Deployments (/docs/compute/deployments) > 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. How deploys create service versions on Prisma Compute, and how to inspect, promote, roll back, start, and stop them. Location: Compute > Deployments A deploy produces a **version** of a service: one built artifact that can serve traffic. Versions live inside a [branch](https://www.prisma.io/docs/compute/branching), and the live version is the one currently serving requests. ## Where versions come from [#where-versions-come-from] Versions are created four ways: * **A git push.** After you [set up deploy on push](https://www.prisma.io/docs/compute/deploy-on-push), your repository's GitHub Actions workflow builds each pushed branch and runs `deploy` on its [Prisma Composer](https://www.prisma.io/docs/composer) module: the default Git branch deploys to production, and every other branch gets an isolated preview. * **The [Console](https://pris.ly/pdp).** Trigger a build and deploy from the browser. * **[`deploy`](https://www.prisma.io/docs/cli/deploy).** For a [Prisma Composer](https://www.prisma.io/docs/composer) app, `deploy` assembles the services you have already built and provisions them from your terminal or CI. * **The [REST API](https://www.prisma.io/docs/rest-api), without Composer.** `POST /v1/services/{serviceId}/deployments` creates a version and returns a pre-signed upload URL for your built artifact; the endpoint is marked experimental in the [OpenAPI specification](https://api.prisma.io/v1/swagger-editor). Tools such as [Alchemy](https://www.prisma.io/docs/compute/alchemy) deploy this way. The `service` commands below manage the versions those flows create. They are targeted explicitly: the service is the first positional argument, and version-scoped commands take a globally unique version id, so there is no interactive picker and no dependence on your current git branch. ## Inspect services and versions [#inspect-services-and-versions] #### bun ```bash bunx prisma service show web bunx prisma service open web bunx prisma service version list web bunx prisma service version show ver_123 ``` #### pnpm ```bash pnpm prisma service show web pnpm prisma service open web pnpm prisma service version list web pnpm prisma service version show ver_123 ``` #### yarn ```bash yarn prisma service show web yarn prisma service open web yarn prisma service version list web yarn prisma service version show ver_123 ``` #### npm ```bash npx prisma service show web npx prisma service open web npx prisma service version list web npx prisma service version show ver_123 ``` `service show` describes the service and its live version, `service open` opens its URL, `version list` lists the version history, and `version show` shows one version in detail. ## Logs [#logs] Read a version's logs with `service logs`. It defaults to the live version; `--version-id ` selects another: #### bun ```bash bunx prisma service logs web --follow bunx prisma service logs web --version-id ver_123 --tail 200 ``` #### pnpm ```bash pnpm prisma service logs web --follow pnpm prisma service logs web --version-id ver_123 --tail 200 ``` #### yarn ```bash yarn prisma service logs web --follow yarn prisma service logs web --version-id ver_123 --tail 200 ``` #### npm ```bash npx prisma service logs web --follow npx prisma service logs web --version-id ver_123 --tail 200 ``` Build output for a deploy is available in the [Console](https://pris.ly/pdp) alongside the version it produced. ## Promote and roll back [#promote-and-roll-back] Promote a preview version to production: #### bun ```bash bunx prisma service version promote ver_123 ``` #### pnpm ```bash pnpm prisma service version promote ver_123 ``` #### yarn ```bash yarn prisma service version promote ver_123 ``` #### npm ```bash npx prisma service version promote ver_123 ``` Promotion rebuilds the version with **production** environment variables and makes the result live behind the service's endpoint. The rebuild is what lets a version built for a preview branch pick up production environment variables on its way to production. Roll back production to a previous version. Rollback reuses an existing build, so there is no rebuild step between you and a known-good state: #### bun ```bash bunx prisma service version rollback web bunx prisma service version rollback web --to ver_123 ``` #### pnpm ```bash pnpm prisma service version rollback web pnpm prisma service version rollback web --to ver_123 ``` #### yarn ```bash yarn prisma service version rollback web yarn prisma service version rollback web --to ver_123 ``` #### npm ```bash npx prisma service version rollback web npx prisma service version rollback web --to ver_123 ``` Without `--to`, rollback targets the version before the live one. ## Start, stop, delete [#start-stop-delete] #### bun ```bash bunx prisma service version stop ver_123 bunx prisma service version start ver_123 bunx prisma service version delete ver_123 ``` #### pnpm ```bash pnpm prisma service version stop ver_123 pnpm prisma service version start ver_123 pnpm prisma service version delete ver_123 ``` #### yarn ```bash yarn prisma service version stop ver_123 yarn prisma service version start ver_123 yarn prisma service version delete ver_123 ``` #### npm ```bash npx prisma service version stop ver_123 npx prisma service version start ver_123 npx prisma service version delete ver_123 ``` Stopping a version takes it out of service without deleting its artifact; starting it brings it back. Deleting a version permanently removes it and the artifact it holds, after confirmation. ## Delete a service [#delete-a-service] #### bun ```bash bunx prisma service delete web ``` #### pnpm ```bash pnpm prisma service delete web ``` #### yarn ```bash yarn prisma service delete web ``` #### npm ```bash npx prisma service delete web ``` This permanently deletes the service from the branch you target with `--branch`. Pass `--yes` to skip the confirmation prompt. ## Next steps [#next-steps] * [Environment variables](https://www.prisma.io/docs/compute/environment-variables): persist config across deploys. * [Deploy on push](https://www.prisma.io/docs/compute/deploy-on-push): the push-to-deploy flow in detail. * [Domains](https://www.prisma.io/docs/compute/domains): point a custom domain at production. * [Prisma Composer](https://www.prisma.io/docs/composer): declare the app the `deploy` command deploys. ## Related pages - [`Alchemy`](https://www.prisma.io/docs/compute/alchemy): Provision Prisma Postgres and deploy applications to Prisma Compute in one TypeScript stack. - [`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. - [`Domains`](https://www.prisma.io/docs/compute/domains): Point a custom domain at a production app and the platform verifies DNS and provisions TLS for you. - [`Environment variables`](https://www.prisma.io/docs/compute/environment-variables): Project configuration that gets injected into your deployments, scoped to production, preview, or a single branch. - [`Environments: production, staging and preview branches`](https://www.prisma.io/docs/compute/branching): Each branch maps to a Git branch, such as a preview per feature or a long-lived staging environment, and gets its own Compute services and deployments. Its data stays separate from production when previews use a preview-scoped DATABASE_URL.