Prisma Compute
Deploy TypeScript services alongside Prisma Postgres, with hosting and previews managed together; a preview can have its own databases.
Prisma Compute hosts TypeScript apps (Node.js, Bun or Next.js) next to Prisma Postgres in one project. Generally available since August 2026. Free plan, no credit card. Any Postgres client works; Prisma ORM is optional.
Once you set up deploy on push, every pushed branch gets an isolated environment: its own services, environment variables, and optionally its own Prisma Postgres database. Compute works with any supported TypeScript framework; see the framework guides.
Prisma Compute is unrelated to Palo Alto Networks' Prisma Cloud.
These docs use the Prisma CLI, run as npx prisma@latest. Deployments come from the deploy command for a Prisma Composer app, from a git push once you set up deploy on push, or from the Console. See Deployments for details.
Get started
Deploy your first service
Sign in, deploy a Composer app, and set up deploys on push.
Deploy quickstart
The short path: declare a new app or bring one you have, then deploy it with Composer.
Declare your app with Prisma Composer, whether it has one service or several: you describe each service and the databases it depends on in TypeScript, and one deploy provisions them together.
The model
Compute organizes everything into a few resources:
- A project groups one product or codebase.
- A branch maps to a Git branch in the linked repository. Each branch is an isolated environment with its own services, environment variables, and deployments, and can have its own database.
- A service is an HTTP application, such as a frontend or backend. Each deploy of a service creates a version. One version is live at a time.
The default Git branch (usually main) is the production branch. Every other branch is a preview branch with its own Compute resources: services, deployments, and environment variables. Data isolation is yours to configure. A preview deploy reads the preview-scoped variables. If preview work must not touch production data, point the preview DATABASE_URL at a non-production database. See Environment variables for details. After you set up deploy on push, pushing to a branch deploys that branch from your repository's GitHub Actions.
The animation below shows how a project, its branches, and their infrastructure fit together, and how each branch's variables resolve by scope:
For the full picture, see Branching.
CLI and Console
Use the CLI for anything you want to repeat: local development, CI, and agent workflows. Every command supports a --json flag that switches its output to machine-readable JSON, so scripts and agents can parse results instead of scraping terminal text.
Use the Console to view and manage projects, branches, services, and deployments in a browser instead of running commands.
What to read next
Once you have deployed something, read Deployments for logs, promoting, and rolling back, and Environment variables for configuration per scope. Object storage covers S3-compatible Object Store buckets, next to your databases in the same project. The CLI reference documents every command and flag. For what Compute can and can't do, read the known limitations.