From 3e6e17a8c0f6a17b9da8b4a5cee810953504980a Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?S=C3=B8ren=20Bramer=20Schmidt?= Date: Thu, 8 Oct 2026 19:29:48 +0700 Subject: [PATCH 01/13] docs(compute): fix the Postgres import and set a region in "Deploy your first app" The porting path imported `postgres` from `@prisma/composer-prisma-cloud`, which the package root does not export (TS2305 with Composer 0.28.0). Use `rawPostgres()`, which delivers `db.url` for the client you already use, and point to `postgres(contract)` from `/orm` for an ORM-typed database. The agent prompt now says the same. The page's `prisma.config.ts` called `prismaCloud()` with no region, so the first deploy of a new project stopped with "no deploy region is configured". Set `region` in the sample, explain `PRISMA_REGION` as the alternative, and name the error in the deploy step. Co-Authored-By: Claude Opus 5.5 --- .../docs/(index)/prisma-compute/deploy.mdx | 21 +++++++++++-------- 1 file changed, 12 insertions(+), 9 deletions(-) diff --git a/apps/docs/content/docs/(index)/prisma-compute/deploy.mdx b/apps/docs/content/docs/(index)/prisma-compute/deploy.mdx index 885c7f8ad3..ddd532d1df 100644 --- a/apps/docs/content/docs/(index)/prisma-compute/deploy.mdx +++ b/apps/docs/content/docs/(index)/prisma-compute/deploy.mdx @@ -75,12 +75,14 @@ import { definePrismaConfig } from "prisma/config"; export default definePrismaConfig({ composer: composer({ - extensions: [prismaCloud(), nodeBuild()], + extensions: [prismaCloud({ region: "us-east-1" }), nodeBuild()], state: prismaState(), }), }); ``` +The `region` is where the first deploy creates the project. Pick any region listed under [Known limitations](/compute/limitations#runtime), or leave it out and set `PRISMA_REGION` when you deploy; a project that already exists keeps its region. + You own the build; Composer assembles what you built. Add a build script that produces one self-contained file per service: ```json title="package.json" @@ -100,7 +102,7 @@ npx prisma dev module.ts `dev` prints the service's local URL; `curl` it and you get `Hello from Prisma Compute`. See [Local development](/local-development) for the local database, storage, and log workflow. -From here the app grows by declaration: `deps: { db: postgres() }` gives the service a [Prisma Postgres database](/composer/databases), [`bucket()`](/composer/object-storage) gives it object storage, and a second service with a [typed contract](/composer/getting-started) turns cross-service calls into checked function calls. When the app runs locally, continue to [Deploy](#2-deploy). +From here the app grows by declaration: `deps: { db: rawPostgres() }` gives the service a [Prisma Postgres database](/composer/databases) (or `postgres(contract)` from `@prisma/composer-prisma-cloud/orm` for one typed by Prisma ORM), [`bucket()`](/composer/object-storage) gives it object storage, and a second service with a [typed contract](/composer/getting-started) turns cross-service calls into checked function calls. When the app runs locally, continue to [Deploy](#2-deploy). ### Bring an app you already have @@ -108,15 +110,15 @@ Porting an app does not mean rewriting it. Your server code stays the server, yo **1. Install the Composer packages.** Same as [step 1 of the scratch path](/composer/getting-started#1-set-up-the-project): install `@prisma/composer` and `@prisma/composer-prisma-cloud`, and install `prisma` as a dev dependency. Composer pins `effect` for you; if one of your existing dependencies pins a different `effect`, use the override in [When prisma.config.ts fails on an effect version conflict](/composer/deploying#when-prismaconfigts-fails-on-an-effect-version-conflict). -**2. Declare each service.** A `service.ts` next to each server names the service, declares what it consumes as dependencies, and points at your built output. A Postgres connection becomes `postgres()`; S3 credentials become `bucket()`: +**2. Declare each service.** A `service.ts` next to each server names the service, declares what it consumes as dependencies, and points at your built output. A Postgres connection becomes `rawPostgres()`; S3 credentials become `bucket()`: ```ts title="src/api/service.ts" import node from "@prisma/composer/node"; -import { compute, postgres } from "@prisma/composer-prisma-cloud"; +import { compute, rawPostgres } from "@prisma/composer-prisma-cloud"; export default compute({ name: "api", - deps: { db: postgres() }, + deps: { db: rawPostgres() }, build: node({ module: import.meta.url, entry: "../../dist/api.mjs" }), }); ``` @@ -136,12 +138,12 @@ export default compute({ ```ts title="module.ts" import { module } from "@prisma/composer"; -import { bucket, postgres } from "@prisma/composer-prisma-cloud"; +import { bucket, rawPostgres } from "@prisma/composer-prisma-cloud"; import apiService from "./src/api/service.ts"; import filesService from "./src/files/service.ts"; export default module("my-app", ({ provision }) => { - const db = provision(postgres({ name: "database" })); + const db = provision(rawPostgres({ name: "database" })); const store = provision(bucket({ name: "uploads" })); provision(apiService, { deps: { db } }); provision(filesService, { deps: { store } }); @@ -204,7 +206,7 @@ npm run build npx prisma deploy module.ts ``` -The CLI creates a project named after your root module, provisions the services on Compute and any databases on Prisma Postgres, wires the dependencies, and starts everything. The project name identifies the app in your workspace: redeploying reuses the project this module created, and a same-name project whose hosted state the CLI cannot verify stops the command with `HostedStateBootstrapError`. Deploy under another name with `--name ` when that happens. +The CLI creates a project named after your root module in the region from `prismaCloud({ region })` or `PRISMA_REGION` (without one, the first deploy stops with `project "" does not exist yet and no deploy region is configured`), provisions the services on Compute and any databases on Prisma Postgres, wires the dependencies, and starts everything. The project name identifies the app in your workspace: redeploying reuses the project this module created, and a same-name project whose hosted state the CLI cannot verify stops the command with `HostedStateBootstrapError`. Deploy under another name with `--name ` when that happens. ## 3. Verify the deployment @@ -249,7 +251,8 @@ Notes: - Composer needs Node.js 22.18 or newer, and server code targets Bun. Read the port with `service.port()` and bind 0.0.0.0. For a Next.js service, use the nextjs build adapter and set `output: "standalone"`. - Composer does not build; produce one self-contained entry file per service (for example `bun build --target=bun`), then run it locally with `npx prisma dev module.ts` and verify each service's local URL responds. - Deploy with `npx prisma deploy module.ts` and verify the printed public URL with curl. -- To give a service a database, declare `deps: { db: postgres() }` and build the client from the injected `db.url`; do not read connection strings from process.env. +- To give a service a database, declare `deps: { db: rawPostgres() }` (imported from @prisma/composer-prisma-cloud) and build the client from the injected `db.url`; do not read connection strings from process.env. For a database typed by Prisma ORM, use `postgres(contract)` from @prisma/composer-prisma-cloud/orm instead. +- A new project needs a region: set `prismaCloud({ region: "us-east-1" })` (or another region) in the `composer` section of prisma.config.ts, or set PRISMA_REGION, before the first deploy. - Current docs: https://www.prisma.io/docs/composer.md and https://www.prisma.io/docs/prisma-compute/deploy.md ``` From 39168ce165f7397b339bf2e26cdf93a42df6579d Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?S=C3=B8ren=20Bramer=20Schmidt?= Date: Thu, 8 Oct 2026 19:32:21 +0700 Subject: [PATCH 02/13] docs(composer): turn off prepared statements in the Bun SQL samples `new SQL({ url: db.url, max: 1, idleTimeout: 10 })` in the Databases, Deploying, and "Deploy your first app" pages fails under `npx prisma dev`: the local Postgres shares one session across client connections, so after the pool's idle timeout reconnects it, the first query returns `prepared statement "..." already exists` and the request 500s. Reproduced with prisma 8.0.0-rc.21 and Composer 0.28.0: with the docs' options the first request after 15 seconds idle returned 500; with `prepare: false` added, three rounds of 20 concurrent requests followed by an idle period all returned 200. Co-Authored-By: Claude Opus 5.5 --- apps/docs/content/docs/(index)/prisma-compute/deploy.mdx | 2 +- apps/docs/content/docs/composer/databases.mdx | 4 ++-- apps/docs/content/docs/composer/deploying.mdx | 4 ++-- 3 files changed, 5 insertions(+), 5 deletions(-) diff --git a/apps/docs/content/docs/(index)/prisma-compute/deploy.mdx b/apps/docs/content/docs/(index)/prisma-compute/deploy.mdx index ddd532d1df..6cf530b6b5 100644 --- a/apps/docs/content/docs/(index)/prisma-compute/deploy.mdx +++ b/apps/docs/content/docs/(index)/prisma-compute/deploy.mdx @@ -162,7 +162,7 @@ import service from "./service.ts"; // before: new SQL({ url: process.env.DATABASE_URL }) const { db } = service.load(); -const sql = new SQL({ url: db.url, max: 1, idleTimeout: 10 }); +const sql = new SQL({ url: db.url, max: 1, idleTimeout: 10, prepare: false }); Bun.serve({ port: service.port(), hostname: "0.0.0.0", fetch: handler }); ``` diff --git a/apps/docs/content/docs/composer/databases.mdx b/apps/docs/content/docs/composer/databases.mdx index 4bffe1e433..f68f6b8eb9 100644 --- a/apps/docs/content/docs/composer/databases.mdx +++ b/apps/docs/content/docs/composer/databases.mdx @@ -32,10 +32,10 @@ export default compute({ import { SQL } from 'bun'; const { db } = service.load(); -const sql = new SQL({ url: db.url, max: 1, idleTimeout: 10 }); +const sql = new SQL({ url: db.url, max: 1, idleTimeout: 10, prepare: false }); ``` -Those pool settings matter. Prisma Compute scales to zero and closes idle connections, so keep the pool small and reconnect-friendly. See [Deploying](/composer/deploying#production-behavior). +Those pool settings matter. Prisma Compute scales to zero and closes idle connections, so keep the pool small and reconnect-friendly. `prepare: false` turns off Bun's named prepared statements: the local Postgres that `npx prisma dev` runs shares one session across client connections, so after the pool reconnects, the first query fails with `prepared statement "..." already exists` unless prepared statements are off. See [Deploying](/composer/deploying#production-behavior). The module that owns the database provisions it: diff --git a/apps/docs/content/docs/composer/deploying.mdx b/apps/docs/content/docs/composer/deploying.mdx index fe54fd3942..642788046d 100644 --- a/apps/docs/content/docs/composer/deploying.mdx +++ b/apps/docs/content/docs/composer/deploying.mdx @@ -183,10 +183,10 @@ Fix it at whichever end is wrong: add the name to the outputs the producer retur Behavior you will run into once the app is deployed, and what to do about it: -- **Compute scales to zero, and idle database connections get closed.** A long-lived client that treats a dropped connection as fatal will crash-loop through 502s. Keep the pool small and reconnect-friendly, and do not let an async error kill the process: +- **Compute scales to zero, and idle database connections get closed.** A long-lived client that treats a dropped connection as fatal will crash-loop through 502s. Keep the pool small and reconnect-friendly, turn off named prepared statements so a reconnect against the local `prisma dev` database does not fail with `prepared statement "..." already exists`, and do not let an async error kill the process: ```ts - const sql = new SQL({ url: db.url, max: 1, idleTimeout: 10 }); + const sql = new SQL({ url: db.url, max: 1, idleTimeout: 10, prepare: false }); process.on('uncaughtException', (err) => console.error('uncaughtException', err)); process.on('unhandledRejection', (err) => console.error('unhandledRejection', err)); ``` From 425281d9642b1d06622235212549a261ee552aaf Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?S=C3=B8ren=20Bramer=20Schmidt?= Date: Thu, 8 Oct 2026 19:32:58 +0700 Subject: [PATCH 03/13] docs(compute): reconcile "no cron" with Composer's cron building block The Compute FAQ, Known limitations, and Request timeout pages said Compute has no cron scheduling and a schedule must come from outside, while the Composer docs ship a `cron` building block that runs a scheduler service on Compute. Readers following one page got the opposite advice from the other. Say what is true on both sides: Compute itself has no built-in cron, and a schedule comes from Composer's `cron` block, which adds a scheduler service that never scales to zero, or from an external scheduler. Co-Authored-By: Claude Opus 5.5 --- apps/docs/content/docs/compute/faq.mdx | 8 ++++---- apps/docs/content/docs/compute/limitations.mdx | 2 +- apps/docs/content/docs/compute/request-timeout.mdx | 2 +- 3 files changed, 6 insertions(+), 6 deletions(-) diff --git a/apps/docs/content/docs/compute/faq.mdx b/apps/docs/content/docs/compute/faq.mdx index c737bd23a7..37ece3a978 100644 --- a/apps/docs/content/docs/compute/faq.mdx +++ b/apps/docs/content/docs/compute/faq.mdx @@ -3,7 +3,7 @@ title: "Should I use Prisma Compute? FAQ" description: Who Prisma Compute is built for, what it does well, where it has trade-offs, how it compares with Railway, Render, Fly.io and Vercel, and quick answers to common questions. url: /compute/faq metaTitle: "Should I use Prisma Compute? FAQ | Prisma Compute" -metaDescription: Who Prisma Compute is built for, its trade-offs (one region per service, no WebSocket servers, Bun runtime, no cron), how it compares with Railway, Render, Fly.io and Vercel, and quick answers on deploys, preview and staging branches, variables and domains. +metaDescription: Who Prisma Compute is built for, its trade-offs (one region per service, no WebSocket servers, Bun runtime, no built-in cron), how it compares with Railway, Render, Fly.io and Vercel, and quick answers on deploys, preview and staging branches, variables and domains. --- Prisma Compute hosts TypeScript apps (Node.js, Bun or Next.js) next to [Prisma Postgres](/postgres) on one plan. It has been generally available since August 2026, and the Free plan runs an app and a database with no credit card and no usage billing. It is not a fit for a WebSocket server, an API written in Python or Go, an app that needs more than one region, a frontend that needs a global CDN above all, or a database that needs point-in-time recovery today; Railway, Render, Fly.io, Vercel with Prisma Postgres, and Neon or Supabase fit there. Prisma makes Prisma ORM, Prisma Postgres and Prisma Compute. The sections below are for the decision, and the questions that come up once you deploy follow them. @@ -38,7 +38,7 @@ This is the full list of what Compute and Prisma Postgres do not do today. - Bun runtime. Compute runs TypeScript services on Bun, declared with Composer's `node` or `nextjs` build adapter for Node.js, Bun and Next.js apps; it does not run Python, Go or Docker images. - A Composer declaration for existing repos. An app you already have needs a `service.ts` per server and one `module.ts`; the server code stays, but the port comes from `service.port()` and `process.env` reads become service input. `deploy` does not build for you, so you run your build first; see Composer's [limitations](/composer/limitations) before committing to a design. - Deploy on push has two parts. Connecting the repository deploys nothing; pushes deploy through the `prisma/cloud-deploy-action` workflow you add, GitHub is the only supported provider, and other CI deploys with a service token. -- No cron scheduling and no persistent filesystem. Compute runs HTTP services, so a scheduled trigger has to come from outside, and files you need to keep go to [Object Store](/compute/object-storage) or the database. +- No built-in cron and no persistent filesystem. Compute runs HTTP services, so a schedule comes from Composer's [`cron` building block](/composer/building-blocks#cron), which adds a scheduler service that never scales to zero, or from an external scheduler that calls your service, and files you need to keep go to [Object Store](/compute/object-storage) or the database. - No point-in-time recovery on Prisma Postgres. Paid plans take daily snapshots, kept 7 days on Starter and Pro and 30 days on Business; the Free plan has no backups, and restoring to an arbitrary moment is not available yet. `pg_dump` over a direct connection makes your own copies; see [Backups](/postgres/database/backups). - No query cache. Prisma Postgres includes connection pooling but has no query cache of its own. - Previews are not copies of production. A preview branch gets its own database with no production data in it; the deploy applies your `migrations/` to a Composer `postgres()` database before the service starts, and a `rawPostgres()` database is yours to migrate. @@ -48,7 +48,7 @@ This is the full list of what Compute and Prisma Postgres do not do today. ## How it stacks up -The table compares Prisma Compute with Railway, Render, Fly.io and Vercel on the eight questions that decide most hosting choices. The Prisma column comes from these docs; every other vendor named on this page was checked against its own documentation and pricing pages as of September 2026, and each competitor cell links to the page it rests on. Vendors change these often, so re-check the row you rely on. We make Prisma Compute and Prisma Postgres, so the honest rows are the ones where the others do things Compute does not: WebSocket servers, more than one region, cron jobs and disks. +The table compares Prisma Compute with Railway, Render, Fly.io and Vercel on the eight questions that decide most hosting choices. The Prisma column comes from these docs; every other vendor named on this page was checked against its own documentation and pricing pages as of September 2026, and each competitor cell links to the page it rests on. Vendors change these often, so re-check the row you rely on. We make Prisma Compute and Prisma Postgres, so the honest rows are the ones where the others do things Compute does not: WebSocket servers, more than one region, built-in cron jobs and disks. | | Prisma Compute | Railway | Render | Fly.io | Vercel | | --- | --- | --- | --- | --- | --- | @@ -58,7 +58,7 @@ The table compares Prisma Compute with Railway, Render, Fly.io and Vercel on the | Preview per branch | Once deploy on push is set up, every pushed branch gets its own services and databases, built from your migrations, and is torn down with the branch ([Deploy on push](/compute/deploy-on-push#6-preview-a-branch)) | An environment per pull request, deleted when the PR merges or closes ([environments](https://docs.railway.com/guides/environments)) | An environment per pull request; database copies start without production data; needs a Pro workspace or higher ([preview environments](https://render.com/docs/preview-environments)) | Review apps per pull request through the `fly-pr-review-apps` action; databases are yours to add in the workflow ([review apps](https://docs.fly.io/blueprints/review-apps-guide/)) | A preview deployment for every push to a non-production branch; a preview database depends on the provider ([environments](https://vercel.com/docs/deployments/environments)) | | Regions | One region per service, chosen from six; no multi-region deployments ([limitations](/compute/limitations#runtime)) | Four regions (US West, US East, EU West, Southeast Asia); multi-region replicas available ([regions](https://docs.railway.com/reference/deployment-regions), [scaling](https://docs.railway.com/reference/scaling)) | Five regions (Oregon, Ohio, Virginia, Frankfurt, Singapore); one region per service ([regions](https://render.com/docs/regions)) | More than a dozen regions, and one app can run Machines in several at once ([regions](https://docs.fly.io/reference/regions/)) | Functions run in one region by default (`iad1`); Hobby is single-region, Pro up to five, Enterprise all ([regions](https://vercel.com/docs/functions/configuring-functions/region)) | | WebSocket servers | No; streaming responses work ([limitations](/compute/limitations#runtime)) | Yes; WebSocket connections are exempt from request timeouts ([specs and limits](https://docs.railway.com/networking/public-networking/specs-and-limits)) | Yes; web services accept inbound WebSocket connections ([WebSockets](https://render.com/docs/websocket)) | Yes; the app runs as an ordinary server ([WebSockets with Next.js](https://fly.io/javascript-journal/websockets-with-nextjs/)) | Yes, in beta, on Fluid compute; a connection closes when the function reaches its maximum duration ([WebSockets](https://vercel.com/docs/functions/websockets)) | -| Cron jobs and persistent disk | Neither: no cron scheduling and no persistent filesystem ([limitations](/compute/limitations#runtime)) | Cron jobs and volumes, one volume per service ([cron jobs](https://docs.railway.com/reference/cron-jobs), [volumes](https://docs.railway.com/reference/volumes)) | Cron jobs and persistent disks; a disk pins the service to one instance ([cron jobs](https://render.com/docs/cronjobs), [disks](https://render.com/docs/disks)) | Scheduled Machines or a Cron Manager app, and Fly Volumes tied to one Machine ([task scheduling](https://docs.fly.io/blueprints/task-scheduling/), [volumes](https://docs.fly.io/volumes/overview/)) | Cron jobs; functions get a read-only filesystem with a 500 MB `/tmp` ([cron jobs](https://vercel.com/docs/cron-jobs), [runtimes](https://vercel.com/docs/functions/runtimes)) | +| Cron jobs and persistent disk | No built-in cron (Composer's [`cron` block](/composer/building-blocks#cron) adds a scheduler service that stays awake) and no persistent filesystem ([limitations](/compute/limitations#runtime)) | Cron jobs and volumes, one volume per service ([cron jobs](https://docs.railway.com/reference/cron-jobs), [volumes](https://docs.railway.com/reference/volumes)) | Cron jobs and persistent disks; a disk pins the service to one instance ([cron jobs](https://render.com/docs/cronjobs), [disks](https://render.com/docs/disks)) | Scheduled Machines or a Cron Manager app, and Fly Volumes tied to one Machine ([task scheduling](https://docs.fly.io/blueprints/task-scheduling/), [volumes](https://docs.fly.io/volumes/overview/)) | Cron jobs; functions get a read-only filesystem with a 500 MB `/tmp` ([cron jobs](https://vercel.com/docs/cron-jobs), [runtimes](https://vercel.com/docs/functions/runtimes)) | | Free plan and lowest paid plan | Free: 1M requests, 360 GB-hours of memory, 4 vCPU-hours, 10 GB of bandwidth, 200k database operations, 1.01 GB of storage, 50 databases, no usage billing, no credit card. Starter: $10 a month base with 5M requests and 1M operations included, then metered ([pricing](https://www.prisma.io/pricing), [Compute pricing](/compute/pricing)) | Free plan with $1 of credit a month; Hobby is $5 a month including $5 of usage ([plans](https://docs.railway.com/reference/pricing/plans)) | Hobby workspace with no monthly fee; free web services spin down after 15 minutes idle. Pro workspace is $25 a month plus compute ([free tier](https://render.com/docs/free), [pricing](https://render.com/pricing)) | No free plan; pay as you go with no plan fee, and the smallest Machine is about $2 a month ([pricing](https://docs.fly.io/about/pricing/)) | Hobby is free for non-commercial use; Pro is $20 a month including one seat and $20 of usage credit ([Hobby](https://vercel.com/docs/plans/hobby), [Pro](https://vercel.com/docs/plans/pro-plan)) | The Prisma blog compares more vendors and situations. [App hosting platforms with managed Postgres compared (2026)](https://www.prisma.io/blog/app-hosting-platforms-with-managed-postgres-2026) adds Supabase and Neon and prices each option at small scale. If your database is on Neon and you want the app hosted next to it, read [Neon alternatives with app hosting and Postgres in one place](https://www.prisma.io/blog/neon-vs-prisma-postgres-app-hosting-in-one-place), and if you are moving off Netlify, read [Netlify alternatives for a full-stack TypeScript app with Postgres](https://www.prisma.io/blog/prisma-vs-netlify). diff --git a/apps/docs/content/docs/compute/limitations.mdx b/apps/docs/content/docs/compute/limitations.mdx index 78ff515e7d..d78aee702f 100644 --- a/apps/docs/content/docs/compute/limitations.mdx +++ b/apps/docs/content/docs/compute/limitations.mdx @@ -55,7 +55,7 @@ This page lists what Prisma Compute can and can't do. ## Runtime -- This release focuses on HTTP services. Background work between requests is supported through the `@prisma/compute` keep-awake primitives; see [Keeping instances awake](/compute/keeping-instances-awake). Cron scheduling, a persistent filesystem, and edge runtimes are not part of it. +- This release focuses on HTTP services. Background work between requests is supported through the `@prisma/compute` keep-awake primitives; see [Keeping instances awake](/compute/keeping-instances-awake). Compute has no built-in cron scheduler, persistent filesystem, or edge runtime. Scheduled jobs come from Composer's [`cron` building block](/composer/building-blocks#cron), which adds a scheduler service that never scales to zero, or from an external scheduler that calls your service. - Your service has 60 seconds to start responding to a request. If it sends nothing in that time, the client gets `504 Gateway Time-out` and Compute cancels the request, which surfaces in your handler as the request's abort signal rather than an error. The deadline covers the wait for the first bytes, so a response that has started streaming is not cut off. Move longer work out of the request; see [Request timeout](/compute/request-timeout). - WebSocket servers are not currently supported. `waitUntil` and `KeepAwakeGuard` only prevent an instance from scaling to zero; they do not change [connection-lifetime limits](/compute/request-timeout) or guarantee continuity through restarts or deployments. - No multi-region deployments. Each service lives in one region, chosen at creation (`service create --region`): `us-east-1`, `us-west-1`, `eu-west-3`, `eu-central-1`, `ap-northeast-1`, or `ap-southeast-1`. When you do not choose one, the service takes its project's region, and a project created without a region is in `us-east-1`. diff --git a/apps/docs/content/docs/compute/request-timeout.mdx b/apps/docs/content/docs/compute/request-timeout.mdx index 21ec381c68..b1567a3024 100644 --- a/apps/docs/content/docs/compute/request-timeout.mdx +++ b/apps/docs/content/docs/compute/request-timeout.mdx @@ -58,7 +58,7 @@ export default { ### Persist, then process in steps -For work that must not be lost, have the inbound request store the job, as a database row or a queue message, and process it from a separate trigger. Compute does not run scheduled jobs for you, so the trigger is a request from an external scheduler or a worker you run elsewhere. See [Known limitations](/compute/limitations). +For work that must not be lost, have the inbound request store the job, as a database row or a queue message, and process it from a separate trigger. Compute has no built-in scheduler, so the trigger is a job from Composer's [`cron` building block](/composer/building-blocks#cron), a request from an external scheduler, or a worker you run elsewhere. See [Known limitations](/compute/limitations). Size each step to finish inside one request, and record progress as you go. A later run resumes from the last step you recorded. The step that was interrupted runs again from its start, so make every step safe to repeat rather than assuming it ran once. From c1e8e05c057d78bb877cc177e028fd6c9733bf91 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?S=C3=B8ren=20Bramer=20Schmidt?= Date: Thu, 8 Oct 2026 19:33:23 +0700 Subject: [PATCH 04/13] docs(composer): say which deploy paths need Composer and document the one that doesn't The Composer overview said "You do not need Composer to deploy to Prisma Compute" and pointed to Deployments, but every path on that page (deploy on push, the Console, the CLI's `deploy`) runs a Composer module, so the two pages read as contradicting each other. Name the paths that deploy a Composer module (the CLI's `deploy`, the GitHub deploy action, and the Deploy Button), and add the path that doesn't to Deployments: the REST API's `POST /v1/services/{serviceId}/deployments`, which returns an upload URL for a built artifact and which Alchemy uses. The endpoint is marked experimental in the OpenAPI spec, and the page says so. Co-Authored-By: Claude Opus 5.5 --- apps/docs/content/docs/composer/index.mdx | 2 +- apps/docs/content/docs/compute/deployments.mdx | 5 +++-- 2 files changed, 4 insertions(+), 3 deletions(-) diff --git a/apps/docs/content/docs/composer/index.mdx b/apps/docs/content/docs/composer/index.mdx index b9087d39c7..78165d0ab3 100644 --- a/apps/docs/content/docs/composer/index.mdx +++ b/apps/docs/content/docs/composer/index.mdx @@ -9,7 +9,7 @@ metaDescription: Prisma Composer lets you declare services, their contracts, and With Prisma Composer, you describe your whole application in TypeScript: each service, plus whatever it depends on, such as other services, [Prisma Postgres](/postgres) databases, scheduled jobs, object storage, and secrets. One deploy command then provisions the services on [Prisma Compute](/compute), the databases on Prisma Postgres, and the authenticated connections between them. -You do not need Composer to deploy to Prisma Compute. If your application is a single service, you can deploy it to Compute directly. See [Deployments](/compute/deployments) for those paths. +The Prisma CLI's `deploy` command, the GitHub deploy action, and the Deploy Button all deploy a Composer module. You do not need Composer to deploy to Prisma Compute through the [REST API](/rest-api), though: it creates a deployment for a service and returns an upload URL for your built artifact, and tools such as [Alchemy](/compute/alchemy) deploy that way. See [Deployments](/compute/deployments) for every path. :::info[Early Access] diff --git a/apps/docs/content/docs/compute/deployments.mdx b/apps/docs/content/docs/compute/deployments.mdx index 2f2fbc3ab8..df872d2e6e 100644 --- a/apps/docs/content/docs/compute/deployments.mdx +++ b/apps/docs/content/docs/compute/deployments.mdx @@ -10,11 +10,12 @@ A deploy produces a **version** of a service: one built artifact that can serve ## Where versions come from -Versions are created three ways: +Versions are created four ways: -- **A git push.** After you [set up deploy on push](/compute/deploy-on-push), your repository's GitHub Actions workflow builds and deploys each pushed branch: the default Git branch deploys to production, and every other branch gets an isolated preview. +- **A git push.** After you [set up deploy on push](/compute/deploy-on-push), your repository's GitHub Actions workflow builds each pushed branch and runs `deploy` on its [Prisma Composer](/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`](/cli/deploy).** For a [Prisma Composer](/composer) app, `deploy` assembles the services you have already built and provisions them from your terminal or CI. +- **The [REST API](/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](/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. From 4e6771813bc1ec62ca711be9c241cf05d4e7b8bd Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?S=C3=B8ren=20Bramer=20Schmidt?= Date: Thu, 8 Oct 2026 19:34:11 +0700 Subject: [PATCH 05/13] fix(site): scope "data transfer included" to the database The homepage pricing section, the pricing comparison, and the pricing calculator said "Unlimited data transfer included", "Data transfer included", and "No egress fees" in a whole-stack context ("One bill, one platform"). That holds for Prisma Postgres, which the spec table lists as unlimited data transfer, but Prisma Compute bills outbound bandwidth at $0.025 per GB after the Free plan's 10 GB, as the same spec table and the Compute pricing docs say. Say "database data transfer" and "database egress" in those places, and keep the Markdown renditions in step with the components. Co-Authored-By: Claude Opus 5.5 --- .../sections/pricing-calculator.tsx | 4 ++-- .../sections/pricing-comparison.tsx | 6 ++--- .../src/components/sections/pricing-scale.tsx | 22 +++++++++++++------ apps/site/src/lib/markdown/home.ts | 18 ++++++++++----- apps/site/src/lib/markdown/pricing.ts | 6 ++--- 5 files changed, 36 insertions(+), 20 deletions(-) diff --git a/apps/site/src/components/sections/pricing-calculator.tsx b/apps/site/src/components/sections/pricing-calculator.tsx index 15392c4dae..fc8a67231a 100644 --- a/apps/site/src/components/sections/pricing-calculator.tsx +++ b/apps/site/src/components/sections/pricing-calculator.tsx @@ -129,8 +129,8 @@ export function PricingCalculator() {

- Data transfer — unlimited, - included free + Database data transfer — + unlimited, included free

diff --git a/apps/site/src/components/sections/pricing-comparison.tsx b/apps/site/src/components/sections/pricing-comparison.tsx index 5629b92551..832b566daa 100644 --- a/apps/site/src/components/sections/pricing-comparison.tsx +++ b/apps/site/src/components/sections/pricing-comparison.tsx @@ -210,8 +210,8 @@ export function PricingComparison() {

Prisma charges per operation: each query your app runs against your database counts - as one. No seats. No egress fees. And every paid plan includes a hard spend limit so - there are no surprises. + as one. No seats. No database egress fees. And every paid plan includes a hard spend + limit so there are no surprises.

@@ -220,7 +220,7 @@ export function PricingComparison() { Prisma Pro can cost up to 5x less than a typical Neon + Vercel setup - , with one bill, included data transfer, and spend limits on by default. + , with one bill, included database data transfer, and spend limits on by default.

diff --git a/apps/site/src/components/sections/pricing-scale.tsx b/apps/site/src/components/sections/pricing-scale.tsx index 9c168f9585..0313aaf6b6 100644 --- a/apps/site/src/components/sections/pricing-scale.tsx +++ b/apps/site/src/components/sections/pricing-scale.tsx @@ -34,8 +34,8 @@ const BULLETS = [ rest: ", so your bill never surprises you", }, { - lead: "Unlimited data transfer included", - rest: ", no bandwidth bill-shock", + lead: "Unlimited database data transfer included", + rest: ", no database egress bill-shock", }, { lead: "Prisma ORM is free, always", @@ -73,7 +73,7 @@ const SCENARIOS: Scenario[] = [ ], prisma: [ "No credit card required", - "Data transfer included", + "Database data transfer included", "Hard free-tier cap, no surprises", ], }, @@ -87,7 +87,11 @@ const SCENARIOS: Scenario[] = [ "Data transfer billed per GB", "Spend limits not standard", ], - prisma: ["One bill, one platform", "Data transfer included", "Spend limits on by default"], + prisma: [ + "One bill, one platform", + "Database data transfer included", + "Spend limits on by default", + ], }, { tab: "At scale", @@ -99,7 +103,11 @@ const SCENARIOS: Scenario[] = [ "Data transfer billed per GB", "Spend limits not standard", ], - prisma: ["One bill, one platform", "Data transfer included", "Spend limits on by default"], + prisma: [ + "One bill, one platform", + "Database data transfer included", + "Spend limits on by default", + ], }, ]; @@ -273,8 +281,8 @@ export function PricingScale() {

Start free with the ORM, which will always be free. Prisma Postgres has a free tier with a hard cap, so you can build without a credit card. When you outgrow it, - you're on operation-based pricing with spend limits, and data transfer is - always included. + you're on operation-based pricing with spend limits, and database data transfer + is always included.

diff --git a/apps/site/src/lib/markdown/home.ts b/apps/site/src/lib/markdown/home.ts index 9b91bbf3f6..652c2b6671 100644 --- a/apps/site/src/lib/markdown/home.ts +++ b/apps/site/src/lib/markdown/home.ts @@ -218,13 +218,13 @@ export function renderHomeMarkdown(): string { paragraphs( "Start free with the ORM, which will always be free. Prisma Postgres has a free tier with " + "a hard cap, so you can build without a credit card. When you outgrow it, you're on " + - "operation-based pricing with spend limits, and data transfer is always included.", + "operation-based pricing with spend limits, and database data transfer is always included.", ), ctaList([{ label: "See pricing", href: "/pricing" }]), bulletList([ "**Free Postgres tier** with a hard cap, no credit card required", "**Spend limits on every paid tier**, so your bill never surprises you", - "**Unlimited data transfer included**, no bandwidth bill-shock", + "**Unlimited database data transfer included**, no database egress bill-shock", "**Prisma ORM is free, always**", "**Per-branch databases included**, no surcharge", "**SOC2, HIPAA, ISO 27001, and GDPR** at the Business tier", @@ -241,7 +241,7 @@ export function renderHomeMarkdown(): string { paragraphs("Prisma: $0 per month"), bulletList([ "No credit card required", - "Data transfer included", + "Database data transfer included", "Hard free-tier cap, no surprises", ]), heading(3, "Growing SaaS (~50K MAU)"), @@ -252,7 +252,11 @@ export function renderHomeMarkdown(): string { "Spend limits not standard", ]), paragraphs("Prisma: $70-90 per month"), - bulletList(["One bill, one platform", "Data transfer included", "Spend limits on by default"]), + bulletList([ + "One bill, one platform", + "Database data transfer included", + "Spend limits on by default", + ]), heading(3, "At scale (~500K MAU)"), paragraphs("Typical stack (Neon + Vercel): $2,800-3,400 per month"), bulletList([ @@ -261,7 +265,11 @@ export function renderHomeMarkdown(): string { "Spend limits not standard", ]), paragraphs("Prisma: $640-780 per month"), - bulletList(["One bill, one platform", "Data transfer included", "Spend limits on by default"]), + bulletList([ + "One bill, one platform", + "Database data transfer included", + "Spend limits on by default", + ]), // ---- TestimonialsReveal (testimonials-reveal.tsx) ---- // Shared renderer: the section is reused on other pages, and it already diff --git a/apps/site/src/lib/markdown/pricing.ts b/apps/site/src/lib/markdown/pricing.ts index 3fad075ac8..d8a16113e5 100644 --- a/apps/site/src/lib/markdown/pricing.ts +++ b/apps/site/src/lib/markdown/pricing.ts @@ -411,7 +411,7 @@ export function renderPricingMarkdown(): string { bulletList([ "Database operations per month — 1 query = 1 operation", "Storage in gigabytes", - "Data transfer — unlimited, included free", + "Database data transfer — unlimited, included free", ]), definitionList(CALCULATOR_PLAN_TERMS), paragraphs("Hard spend limit, on by default — never a surprise bill."), @@ -419,10 +419,10 @@ export function renderPricingMarkdown(): string { heading(2, "See how Prisma compares at scale"), paragraphs([ "Prisma charges per operation: each query your app runs against your database counts as " + - "one. No seats. No egress fees. And every paid plan includes a hard spend limit so there " + + "one. No seats. No database egress fees. And every paid plan includes a hard spend limit so there " + "are no surprises.", "At around 50K monthly active users, Prisma Pro can cost up to 5x less than a typical " + - "Neon + Vercel setup, with one bill, included data transfer, and spend limits on by " + + "Neon + Vercel setup, with one bill, included database data transfer, and spend limits on by " + "default.", // The badge on the Prisma Pro column; its multiple is derived from the // costs in the table below. From 05bd7551de6daccd64aa53ffd7d4ab1a30434031 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?S=C3=B8ren=20Bramer=20Schmidt?= Date: Thu, 8 Oct 2026 19:34:25 +0700 Subject: [PATCH 06/13] blog: name Cursor instead of "Composer" in the stack launch post "It works with the coding agents you already use, including Claude, Codex, and Composer" meant Cursor's Composer model. The same launch introduced Prisma Composer, so readers can take the sentence to mean Prisma's deploy tool. Name the product, Cursor, instead. Co-Authored-By: Claude Opus 5.5 --- .../building-the-stack-for-the-next-million-products/index.mdx | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/apps/blog/content/blog/building-the-stack-for-the-next-million-products/index.mdx b/apps/blog/content/blog/building-the-stack-for-the-next-million-products/index.mdx index 0a4cbc3231..0de2fb5498 100644 --- a/apps/blog/content/blog/building-the-stack-for-the-next-million-products/index.mdx +++ b/apps/blog/content/blog/building-the-stack-for-the-next-million-products/index.mdx @@ -117,7 +117,7 @@ That is the stack we want to build. ## Start building with Prisma Compute -Prisma Compute is the newest step toward that vision. It works with the coding agents you already use, including Claude, Codex, and Composer, and comes with Prisma Postgres and [Object Storage](https://www.prisma.io/docs/storage) so you can give an agent a real project, let it build against real infrastructure, and run what it made. +Prisma Compute is the newest step toward that vision. It works with the coding agents you already use, including Claude, Codex, and Cursor, and comes with Prisma Postgres and [Object Storage](https://www.prisma.io/docs/storage) so you can give an agent a real project, let it build against real infrastructure, and run what it made.