Deployments

A deploy produces a version of a service: one built artifact that can serve traffic. Versions live inside a branch, and the live version is the one currently serving requests.

Where versions come from

Versions are created four ways:

• A git push. After you set up deploy on push, your repository's GitHub Actions workflow builds each pushed branch and runs deploy on its Prisma Composer module: the default Git branch deploys to production, and every other branch gets an isolated preview.
• The Console. Trigger a build and deploy from the browser.
• deploy. For a Prisma Composer app, deploy assembles the services you have already built and provisions them from your terminal or CI.
• The 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. Tools such as 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

bunx prisma service show web
bunx prisma service open web
bunx prisma service version list web
bunx 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

Read a version's logs with service logs. It defaults to the live version; --version-id <id> selects another:

bunx prisma service logs web --follow
bunx prisma service logs web --version-id ver_123 --tail 200

Build output for a deploy is available in the Console alongside the version it produced.

Promote and roll back

Promote a preview version to production:

bunx 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:

bunx prisma service version rollback web
bunx prisma service version rollback web --to ver_123

Without --to, rollback targets the version before the live one.

Start, stop, delete

bunx prisma service version stop ver_123
bunx prisma service version start ver_123
bunx 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

bunx 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

• Environment variables: persist config across deploys.
• Deploy on push: the push-to-deploy flow in detail.
• Domains: point a custom domain at production.
• Prisma Composer: declare the app the deploy command deploys.