# Where to host a TypeScript frontend, Node API and Postgres in 2026: Prisma Compute, Railway, Render, Fly.io and Vercel compared URL: https://www.prisma.io/blog/where-to-host-typescript-frontend-node-api-postgres Published: 2026-09-22 Updated: 2026-11-12 Authors: Gregory Boch Tags: platform, prisma-postgres Description: Prisma Compute, Railway, Render, Fly.io and Vercel compared for a TypeScript frontend, Node API and Postgres from one GitHub repo: verdict table, prices, limits. > Blog posts describe Prisma as it was on the date shown and are not kept current. Before implementing from a post, check the documentation index at https://www.prisma.io/docs/llms.txt and the changelog at https://www.prisma.io/changelog.md. > For an index of every published post, fetch https://www.prisma.io/blog/llms.txt. Five platforms host a TypeScript frontend, a Node API and a Postgres database from one GitHub repository: Prisma Compute with Prisma Postgres, Railway, Render, Fly.io, and Vercel with a Marketplace database such as Prisma Postgres, Neon or Supabase. They differ on how much of the repository changes, who runs the database, what an idle app costs and whether each pushed branch gets a preview with its own database. On Prisma Compute, one command after your build, `npx prisma deploy`, provisions the frontend and the API on Compute and the database on Prisma Postgres, in one project and region. Before the first deploy, your coding agent can add a [Prisma Composer](https://www.prisma.io/docs/composer) declaration around each server, make [the three server changes](#can-i-host-my-existing-github-repo-on-prisma) to how each one reads its port, settings and database URL, and show you the diff; your server code stays the server, with those changes. Prisma Compute runs the frontend, when Next.js, Astro, TanStack Start or your own Node.js or Bun server serves it, and the API next to managed PostgreSQL 17 with PgBouncer pooling. The Free plan has no usage billing, and Starter is a $10 base with Compute usage metered on top. Neither product needs Prisma ORM. We make Prisma Compute and Prisma Postgres. ## Quick recommendation [#quick-recommendation] If you want one provider, one project and one bill for the frontend, the API and the database, deployed together from one GitHub repository, use Prisma Compute, generally available since August 2026, with Prisma Postgres (neither product needs Prisma ORM): the Free plan has no usage billing, and Starter is $10 a month base with 5M requests and 1M database operations included, then metered. If the app already runs on another host and you only need the database, use Prisma Postgres on its own, because it is managed PostgreSQL 17 with pooling included and any host reaches it by connection string. For WebSocket servers, APIs in other languages, more than one region or your own Docker image, see [Where Prisma is the wrong choice](#where-prisma-is-the-wrong-choice). If the repository instead contains several independent business apps, use the [multiple-app hosting guide](https://www.prisma.io/compute/multiple-business-apps) to decide which projects, databases and release procedures should stay separate. ## Steps from repo to running app [#steps-from-repo-to-running-app] Here are the steps for Prisma Compute with Prisma Postgres, Railway and Render, in the order of the sections below, as each one's docs describe them. **Prisma Compute with Prisma Postgres** 1. Hand your coding agent the porting guide's [prompt](https://www.prisma.io/docs/composer/porting-an-app#use-with-your-agent) from the project root: it declares each server as a service with `compute()`, composes them in one `module.ts`, makes the three server changes, verifies with `npx tsc --noEmit` and a local `npx prisma dev` run, and shows you the diff before any deploy. To make the changes yourself instead, add a `service.ts` next to each server, one `module.ts` that declares the services and the database, and `entry: './module.ts'` in the `composer` section of `prisma.config.ts`, which is where the CLI finds the app; then make the three server changes: read the port from `service.port()` and bind `0.0.0.0`, turn the other `process.env` reads into service inputs or dependencies, and build the Postgres client from the injected `db.url`. 2. Run your build, then `npx prisma deploy`. The first deploy creates the project, provisions the services on Compute and the database on Prisma Postgres, and needs a region. There is no `DATABASE_URL` to copy: each service receives its database URL as `db.url`. 3. With `postgres()` and a Prisma ORM data contract, the deploy applies your committed migrations before the service starts; with `rawPostgres()`, you run your migrations as you do today ([Composer databases](https://www.prisma.io/docs/composer/databases)). 4. For deploy on push, [link the directory](https://www.prisma.io/docs/compute/deploy-on-push#2-link-the-directory-to-the-project) to the project with `npx prisma project link `, since the deploy creates the project but does not link the directory, then run `npx prisma git connect` and commit a workflow that runs `prisma/cloud-deploy-action`. The default branch then deploys production, and every other pushed branch gets a preview with its own services and, for databases declared in the Composer module, its own new database; production data is not copied. **Railway** 1. Create a service from the GitHub repository with [Connect Repo](https://docs.railway.com/services#deploying-from-a-github-repo); it [deploys automatically](https://docs.railway.com/deployments/github-autodeploys) when new commits are pushed to the connected branch. Railway builds the repository with [Railpack](https://docs.railway.com/builds/railpack), with zero configuration for the languages Railpack supports, or uses a [Dockerfile](https://docs.railway.com/builds/dockerfiles) at the root of the source directory. 2. Add the [PostgreSQL template](https://docs.railway.com/databases/postgresql), which deploys a single node that Railway maintains; backups, point-in-time recovery, high availability and PgBouncer pooling are opt-in in its docs. 3. On the app service, set `DATABASE_URL` as a [reference variable](https://docs.railway.com/variables#reference-variables) to the PostgreSQL service's `DATABASE_URL`, for example `${{ Postgres.DATABASE_URL }}` when that service is named Postgres. 4. For previews, turn on PR environments in Project Settings, Environments. Each pull request then gets one, deleted when the pull request is merged or closed ([environments](https://docs.railway.com/environments)). **Render** 1. Create a Render Postgres database. A [free one](https://render.com/docs/free) expires 30 days after creation, and the smallest paid one is $6 a month ([render.com/pricing](https://render.com/pricing)). 2. Create a web service from the GitHub repository, in the database's region; the Render GitHub app [redeploys it on every push](https://render.com/docs/git-provider) to its linked branch. Set the environment variable your app reads, such as `DATABASE_URL`, to the database's [internal URL](https://render.com/docs/postgresql-creating-connecting#internal-connections). 3. Run migrations with a [pre-deploy command](https://render.com/docs/deploys), which is available only on paid web services, private services and background workers, not on free web services. 4. For previews, use a Pro workspace or higher. Define the web service and the database in a `render.yaml` Blueprint, set `DATABASE_URL` there with a [`fromDatabase` reference](https://render.com/docs/blueprint-spec#referencing-service-properties) to the database's `connectionString` instead of a pasted production URL, which each preview would keep, and set `previews.generation` to `automatic`, or to `manual` and add `[render preview]` to a pull request's title ([preview environments](https://render.com/docs/preview-environments)). A preview copies the services and databases the Blueprint defines, without their data. [The port, step by step](#the-port-step-by-step) has the Prisma files and the workflow in full. ## Your situation, and what to pick [#your-situation-and-what-to-pick] | Your situation | Pick | Why | | ------------------------------------------------------------------------------------------------- | -------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Existing GitHub repo with a TypeScript frontend and a Node API, and a coding agent to do the port | Prisma Compute + Prisma Postgres | Your coding agent runs the porting guide's [prompt](https://www.prisma.io/docs/composer/porting-an-app#use-with-your-agent) from the project root: it declares each server as a service, makes the three server changes and shows you the diff before any deploy; this fits a frontend served by Next.js, Astro, TanStack Start or your own Node.js or Bun server. After your build, with a region set for the new project, [`npx prisma deploy`](https://www.prisma.io/docs/cli/deploy) creates the project, with the services on Compute and the database on Prisma Postgres. Once [deploy on push](https://www.prisma.io/docs/compute/deploy-on-push) is set up (link the directory, run `npx prisma git connect` and commit the `prisma/cloud-deploy-action` workflow), each push deploys: the default branch to production, any other branch to a preview. | | Frontend and Node API from one repo, free to start | Prisma Compute + Prisma Postgres | The Free plan is $0 with no credit card, no time limit and no usage billing, and covers both services and the database in one project: 1M requests, 360 GB-hours of memory, 4 active vCPU-hours and 10 GB of outbound bandwidth a month on Compute, and 200k operations, 2 GB of storage and 50 databases on Prisma Postgres, with no backups ([prisma.io/pricing](https://www.prisma.io/pricing), as of October 2026). An existing repo adds a Prisma Composer declaration next to each server, which a coding agent can write, and changes how each server reads its port, settings and database URL; [Should I use Prisma Compute for an existing GitHub repo?](https://www.prisma.io/docs/compute/faq#should-i-use-prisma-compute-for-an-existing-github-repo) covers what to add. | | Side project or hobby app that should stay at $0 | Prisma Compute + Prisma Postgres | The Free plan has no time limit. When a month's 200k operations run out, the database stops accepting reads and writes until you upgrade or the next month starts, and a 24-hour grace period, available once per workspace, can lift the limit ([Postgres FAQ](https://www.prisma.io/docs/postgres/faq#what-happens-if-i-exceed-the-included-queries-on-the-free-tier)). A free Render Postgres expires 30 days after creation, and Railway's Free plan is $1 of usage credit a month after a trial with $5 of credit, which ends after 30 days or when the credit is spent. New Fly.io organizations get a trial, not a free tier, and once a credit card is on file Fly.io waives a personal organization's monthly bill under $5; Fly.io's Managed Postgres starts at $38 a month. | | I just want it deployed from GitHub, everything in one project | Prisma Compute + Prisma Postgres | Free plan, no usage billing. Deploy the Composer module with `npx prisma deploy`, then connect the repository and add the `prisma/cloud-deploy-action` workflow for deploy on push. | | Small production app with a preview for each pushed branch other than the default | Prisma Compute + Prisma Postgres | Starter is $10 a month base with 5M requests and 1M operations included, then metered. With deploy on push set up, every pushed branch other than the default one gets a preview with its own services and, for databases declared in the Composer module, its own new database; production data is not copied, and a push to the default branch deploys production. | | Next.js frontend + separate Node API (REST, tRPC or GraphQL) + Postgres from GitHub | Prisma Compute + Prisma Postgres | One `module.ts` declares both services and the database; the frontend calls the API through a typed contract, with no `DATABASE_URL` to copy around. | | Vite or React single-page app + Node API + Postgres from GitHub | Prisma Compute + Prisma Postgres | Compute runs a server process, not a folder of files, so your own Node.js or Bun server serves the built files, as the [Astro marketing site guide](https://www.prisma.io/docs/guides/compute/astro-marketing-site) does with prebuilt pages; the API and the database go in the same `module.ts`. Prisma Compute is not a CDN or edge platform, so a frontend that needs a global CDN above all fits the Vercel row below. | | App stays on Railway, Render, Fly.io or Vercel; you want managed Postgres | Prisma Postgres | PostgreSQL 17 with PgBouncer pooling included. Free has 200k operations a month and needs no credit card, and any Postgres client connects with the connection string. | | WebSockets, a non-TypeScript API, more than one region or your own Docker image | Railway, Render or Fly.io | See [Where Prisma is the wrong choice](#where-prisma-is-the-wrong-choice). | | Frontend needs a global CDN above all | Vercel + Prisma Postgres | Vercel's CDN serves the frontend; the API reaches Prisma Postgres by connection string from anywhere. | ## Prisma Compute vs Railway vs Render vs Fly.io vs Vercel: what differs [#prisma-compute-vs-railway-vs-render-vs-flyio-vs-vercel-what-differs] The Compute FAQ answers [Should I use Prisma Compute for an existing GitHub repo?](https://www.prisma.io/docs/compute/faq#should-i-use-prisma-compute-for-an-existing-github-repo), and [Can I host my existing GitHub repo on Prisma?](#can-i-host-my-existing-github-repo-on-prisma) below lists the server changes. ### 1. Prisma Compute + Prisma Postgres [#1-prisma-compute--prisma-postgres] **Best for:** a TypeScript frontend and Node API that ship with their database from one repository in one project. Neither product needs Prisma ORM. **What it does.** Prisma Compute hosts TypeScript services (Node.js, Bun or Next.js) next to Prisma Postgres and has been generally available since August 2026. With Prisma Composer you describe each service, its database and the calls between them in TypeScript. `npx prisma dev` runs it locally with a local Postgres, and `npx prisma deploy` provisions the services on Compute and the database on Prisma Postgres, which is managed PostgreSQL 17 with PgBouncer pooling included and no point-in-time recovery yet (coming in November 2026); any Postgres client works. With deploy on push set up, the default branch deploys production and every other branch gets a preview with its own services and database. **Pricing.** Free: app and database with no usage billing (1M requests, 360 GB-hours of memory, 4 vCPU-hours, 10 GB of bandwidth, 200,000 operations, 2 GB of storage and 50 databases). Starter: $10 a month base with 5M requests and 1M operations included, 10 GB of storage and daily backups kept 7 days; memory ($0.006 per GB-hour), active vCPU ($0.064 per hour) and bandwidth ($0.025 per GB) are metered from the first unit, with requests at $1 per million and operations at $8 per million beyond that ([prisma.io/pricing](https://www.prisma.io/pricing), as of October 2026). **Trade-offs.** No WebSocket servers today (support is planned for early 2027), one region per service and no point-in-time recovery yet (coming in November 2026). [Where Prisma is the wrong choice](#where-prisma-is-the-wrong-choice) below covers each case, and [Where it has trade-offs](https://www.prisma.io/docs/compute/faq#where-it-has-trade-offs) in the Compute FAQ is the full list. **How we compared.** We make Prisma Compute and Prisma Postgres. Railway, Render, Fly.io and Vercel were checked against their own documentation and pricing on 2026-09-30, their build, preview and database facts again on 2026-10-08, Railway's pricing and Fly.io's pricing, Fly Launch and Managed Postgres pages again on 2026-10-14, and Railway's pricing and free trial and Render's free-instance page again on 2026-10-21; the database section was checked against Neon's and Supabase's docs on 2026-10-07. Sources are linked inline and under Sources. **Compare:** [Prisma Compute vs Vercel pricing](https://www.prisma.io/blog/prisma-compute-vs-vercel-pricing), [Neon vs Prisma Postgres for hosting and the database in one place](https://www.prisma.io/blog/neon-vs-prisma-postgres-app-hosting-in-one-place), and [choosing hosting and Postgres after your first 100 paying users](https://www.prisma.io/blog/choosing-hosting-and-postgres-after-your-first-100-users). ### 2. Railway [#2-railway] **Best for:** a service that holds WebSocket connections open, next to a Postgres template Railway maintains. **What it does.** The Railway GitHub app [deploys on every push](https://docs.railway.com/deployments/github-autodeploys), and once you turn on PR environments in the project settings, a pull request gets its own environment, deleted on merge or close. Railway maintains its Postgres template; backups, point-in-time recovery, high availability and PgBouncer pooling are opt-in in its docs (checked 2026-10-08). [What Railway manages](https://docs.railway.com/databases#what-railway-manages) lists who handles each operation, and daily [backups](https://docs.railway.com/volumes/backups) are kept for 6 days. WebSocket connections are supported, and a service can [opt into Serverless](https://docs.railway.com/deployments/serverless), which sleeps it after five to ten idle minutes. **Pricing.** Free $0 with $1 of credit a month after a trial with $5 of credit, which ends after 30 days or when the credit is spent ([free trial](https://docs.railway.com/pricing/free-trial)); Hobby $5 a month with $5 of usage included, Pro $20 with $20 included; memory about $10 per GB a month, CPU about $20 per vCPU a month, egress $0.05 per GB ([railway.com/pricing](https://railway.com/pricing), as of October 2026). **Trade-offs.** Previews are per pull request, not per branch, and the opt-in database features above stay off until you turn them on. **Compare:** [Netlify alternatives for a TypeScript app with Postgres](https://www.prisma.io/blog/prisma-vs-netlify), which profiles Railway beside Prisma, Vercel, Render, Supabase and Neon, and [choosing hosting and Postgres after your first 100 paying users](https://www.prisma.io/blog/choosing-hosting-and-postgres-after-your-first-100-users), which sets a long-lived Railway service against Compute. **For this repo, vs Prisma Compute:** If you want to avoid code changes, Railway builds the repository with zero configuration for Node, Python, Go and the other languages [Railpack](https://docs.railway.com/builds/railpack) supports, or from a [Dockerfile](https://docs.railway.com/builds/dockerfiles) at its root. It also keeps WebSocket connections open and offers the opt-in point-in-time recovery and high availability above. Prisma Compute gives every pushed branch other than the default one, not only pull requests, a preview with its own services and, for databases declared in the Composer module, its own new database; Prisma Postgres includes pooling on every plan. ### 3. Render [#3-render] **Best for:** a web service that holds WebSocket connections open next to a managed Postgres, if you pay for a Pro workspace to get preview environments. **What it does.** The Render GitHub app [redeploys on every push](https://render.com/docs/git-provider), and on a Pro workspace or higher, once the Blueprint sets `previews.generation` to `automatic` (or to `manual`, with `[render preview]` in the pull request's title), preview environments copy your services and datastores for a pull request, without the data. Postgres is managed, with PgBouncer pooling toggled on for paid databases, and [WebSocket connections are supported](https://render.com/docs/websocket). A [free web service](https://render.com/docs/free) spins down after 15 idle minutes and takes about a minute to spin back up, and a free Postgres expires after 30 days. **Pricing.** Hobby workspace $0; in [Render's own July 2026 example](https://render.com/articles/how-much-does-cloud-application-hosting-cost-for-small-businesses) an always-on Starter web service plus a basic-256mb Postgres came to about $13 a month before storage and bandwidth, and preview environments need the Pro workspace at $25 a month ([render.com/pricing](https://render.com/pricing), as of September 2026). **Trade-offs.** Preview environments need a paid workspace, and free databases have no pooling. A free web service spins down after 15 minutes without inbound traffic and takes about a minute to start again on its next request, while a free Render Postgres database does not spin down when idle but expires 30 days after creation. **Compare:** [Netlify alternatives for a TypeScript app with Postgres](https://www.prisma.io/blog/prisma-vs-netlify), which profiles Render and puts it in the feature table, and [choosing hosting and Postgres after your first 100 paying users](https://www.prisma.io/blog/choosing-hosting-and-postgres-after-your-first-100-users), which covers Render's pooling and WebSocket support. **For this repo, vs Prisma Compute:** Render builds Node.js, Bun, Python, Ruby, Go, Rust and Elixir services [natively](https://render.com/docs/language-support), or nearly any other language from a Docker image, keeps WebSocket connections open, and its paid Postgres databases have [point-in-time recovery](https://render.com/docs/postgresql-backups). Prisma Compute gives every pushed branch other than the default one a preview with its own services and, for databases declared in the Composer module, its own new database, where Render's preview environments, once turned on in the Blueprint, are per pull request on a Pro workspace or higher. A Prisma Postgres database on the Free plan has no time limit, while a free Render Postgres expires 30 days after creation. ### 4. Fly.io [#4-flyio] **Best for:** more than one region, custom networking, or a Docker image run as it is. **What it does.** Fly runs your image as Machines in the regions you choose, which can [stop when idle and start on request](https://docs.fly.io/launch/autostop-autostart/). Deploy on push is a [GitHub Actions workflow](https://docs.fly.io/launch/continuous-deployment-with-github-actions/) running `flyctl` with a `FLY_API_TOKEN` secret, and review apps come from Fly's action, one app per pull request. Managed Postgres includes high availability, backups and pooling on every plan, and [WebSocket connections are supported](https://fly.io/blog/websockets-and-fly/). A Managed Postgres cluster is [created in one region](https://docs.fly.io/postgres/create-and-connect/) you choose, while the app's Machines can [run in several regions](https://docs.fly.io/launch/scale-count/) at once. **Pricing.** Pay as you go with no plan fee. New organizations get no free tier; a new account gets a free trial of $1 of credit for Machines, Sprites and Managed Postgres, which lasts 7 days or until it is used up, with no credit card needed to start. Once a credit card is on file, Fly.io waives the monthly bill of your personal organization, the one created at signup, when it comes to less than $5; a bill of $5 or more is charged in full, and organizations you create or join get no waiver. A stopped Machine bills only its root filesystem, $0.15 per GB for 30 days. Managed Postgres starts at $38 a month for the Basic plan plus $0.28 per GB of storage ([pricing](https://docs.fly.io/about/pricing/), [free waiver](https://docs.fly.io/about/free-waiver/) and [Managed Postgres](https://docs.fly.io/postgres), as of November 2026). **Trade-offs.** On the app side, you keep a Dockerfile and a `fly.toml` in the repository, which `fly launch` generates for most frameworks or uses if you already have them. The database is Fly.io's Managed Postgres (`fly mpg`), which Fly.io runs, from $38 a month. The older [`fly postgres`](https://docs.fly.io/flyctl/cmd/fly_postgres/) commands manage the [legacy unmanaged Fly Postgres](https://docs.fly.io/unmanaged-postgres/), which Fly.io no longer maintains or supports. **Compare:** [App hosting platforms with managed Postgres compared](https://www.prisma.io/blog/app-hosting-platforms-with-managed-postgres-2026), which puts Fly.io in a table beside Prisma, Railway, Render, Supabase, Neon and Vercel; the [Where Prisma is the wrong choice](#where-prisma-is-the-wrong-choice) section below covers the cases that send you to Fly.io. **For this repo, vs Prisma Compute:** Fly.io runs your Docker image as Machines in the regions you choose, with the Managed Postgres cluster in [one region you choose](https://docs.fly.io/postgres/create-and-connect/), keeps WebSocket connections open, and includes high availability, backups and pooling on every [Managed Postgres](https://docs.fly.io/postgres) plan. Prisma Compute runs the app and its database on a Free plan with no usage billing, where Managed Postgres on Fly.io starts at $38 a month; one deploy workflow gives every pushed branch other than the default one a preview, where Fly's review apps are per pull request. ### 5. Vercel [#5-vercel] **Best for:** a frontend whose main requirement is a global CDN, with the API and database elsewhere. **What it does.** Vercel [deploys on every push](https://vercel.com/docs/git) and gives every non-production branch a preview deployment. It hosts no Postgres of its own, so the setup is Vercel with a Marketplace database such as [Prisma Postgres](https://vercel.com/marketplace/prisma), Neon or Supabase, or any Postgres reached by connection string. [WebSocket support in Vercel Functions](https://vercel.com/docs/functions/websockets) is generally available on all plans since 2026-10-20, and a connection closes at the function's maximum duration. **Pricing.** Hobby $0 for personal, non-commercial use; Pro $20 a month, which includes one deploying seat, $20 of usage credit and 1 TB of CDN data transfer; function invocations draw on the credit at $0.60 per million, then bill on demand ([vercel.com/pricing](https://vercel.com/pricing) and the [Pro plan](https://vercel.com/docs/plans/pro-plan), as of September 2026). **Trade-offs.** No database of its own, and the Hobby plan excludes commercial use. **Compare:** [Prisma vs Vercel](https://www.prisma.io/blog/prisma-vs-vercel). **For this repo, vs Prisma Compute:** Vercel serves the frontend from its [global CDN](https://vercel.com/docs/cdn), builds on its own machines and gives every non-production branch a preview deployment. Prisma Compute runs the API as a TypeScript server on Bun, next to Prisma Postgres in one project and region, with the database declared in the same Composer module, where on Vercel an Express API runs as a [Vercel Function](https://vercel.com/docs/frameworks/backend/express) and the database is a separate Marketplace integration. ## Just the database: Prisma Postgres for an app on Railway, Render, Fly.io, Vercel or Netlify [#just-the-database-prisma-postgres-neon-or-supabase] If the frontend stays on Vercel or Netlify and the API on Railway or Render, use [Prisma Postgres](https://www.prisma.io/postgres) as the database: PostgreSQL 17 with [PgBouncer pooling](https://www.prisma.io/docs/postgres/database/connection-pooling) included, reached by connection string, Free with 200k operations a month and no credit card. The same goes for an app that already runs entirely on Railway, Render, Fly.io, Vercel or Netlify and only needs a managed database: `pg`, Drizzle, Kysely, `psql` or Prisma ORM all connect with the connection string, and nothing about your hosting changes. Pick the region closest to the app from the [six regions](https://www.prisma.io/docs/postgres/faq#what-regions-is-prisma-postgres-available-in), because every query crosses the network between the providers. Free also includes 50 databases. Starter is $10 a month with 1M operations and 10 GB of storage included, then $8 per million operations and $2 per GB, and data transfer is unlimited on every plan ([prisma.io/pricing](https://www.prisma.io/pricing), as of October 2026). Neon or Supabase is the pick if you need point-in-time recovery today. Prisma Postgres keeps [daily snapshots](https://www.prisma.io/docs/postgres/database/backups) on paid plans, for 7 days on Starter and Pro and 30 on Business, and has no point-in-time recovery yet; it is coming in November 2026. Neon's [instant restore](https://neon.com/docs/postgres/backup-restore/branch-restore) returns a root branch to any moment in its history window, and Supabase sells [point-in-time recovery](https://supabase.com/docs/guides/platform/backups) as an add-on on Pro and higher plans (as of November 2026). ## Can I host my existing GitHub repo on Prisma? [#can-i-host-my-existing-github-repo-on-prisma] Yes, and you keep the database client you have: `pg`, Drizzle, Prisma ORM or any other Postgres client builds from the connection string the service receives, and you run migrations as you do today. What you add is a [Prisma Composer](https://www.prisma.io/docs/composer) declaration around each server: a `service.ts` next to it, one root `module.ts` that composes the services, and the `composer` section in `prisma.config.ts`, which only the CLI reads and whose `entry: './module.ts'` names the module that `npx prisma dev` and `npx prisma deploy` load. Today every deploy needs this declaration; deploying an existing repository without a Composer file is planned for early 2027. The server itself needs the three changes that [Port an existing app](https://www.prisma.io/docs/composer/porting-an-app) lists: it reads its port from `service.port()` and binds `0.0.0.0`, its other `process.env` reads become service inputs or dependencies, and it builds its database client from the injected `db.url` instead of `process.env.DATABASE_URL`. The guide covers a Node.js or Bun service, a Next.js app and several services together, and a coding agent can make these changes from its [porting prompt](https://www.prisma.io/docs/composer/porting-an-app#use-with-your-agent). After your build, `npx prisma deploy` deploys the app, and once you connect the repository and add the `prisma/cloud-deploy-action` workflow, every push deploys. For an API that keeps its current Postgres client, the declaration looks like this: ```ts title="api/service.ts" import node from '@prisma/composer/node'; import { compute, rawPostgres } from '@prisma/composer-prisma-cloud'; export default compute({ name: 'api', deps: { db: rawPostgres() }, build: node({ module: import.meta.url, entry: '../dist/server.mjs' }), }); ``` ```ts title="module.ts" import { module } from '@prisma/composer'; import { rawPostgres } from '@prisma/composer-prisma-cloud'; import apiService from './api/service.ts'; export default module('my-app', ({ provision }) => { const db = provision(rawPostgres({ name: 'database' })); provision(apiService, { deps: { db } }); }); ``` `rawPostgres()` delivers `{ url }`, and you build `pg`, Drizzle or whichever client you use today from it. The Next.js frontend gets its own `service.ts` with the `nextjs` build adapter, and `module.ts` provisions it beside the API. If you want the deploy to apply migrations for you, declare `postgres()` with a [Prisma ORM 8](https://www.prisma.io/docs/orm) data contract instead; Prisma ORM 8 does not have every Prisma ORM 7 feature yet, and [what is not available yet](https://www.prisma.io/docs/orm/coming-from-prisma-orm-7#not-available-yet) lists them. ### Hand it to your agent [#hand-it-to-your-agent] The porting guide ships a [prompt for a coding agent](https://www.prisma.io/docs/composer/porting-an-app#use-with-your-agent) that surveys every server and its `process.env` reads, writes the `compute()` declarations and `module.ts`, builds the existing database client from the injected `db.url`, verifies with `npx tsc --noEmit` and `npx prisma dev`, and shows the diff before deploying. The [Prisma MCP server](https://www.prisma.io/docs/ai/tools/mcp-server) at `mcp.prisma.io` connects Claude, ChatGPT, Cursor, Codex and other MCP clients to your workspace, every CLI command accepts `--json`, `--format markdown` and `--no-interactive`, and the [Codex plugin](https://www.prisma.io/docs/ai/tools/codex) bundles both. Ali Fatemi, who had Claude deploy generated sites to Compute, [said](https://www.prisma.io/blog/claude-generated-50-websites-overnight-prisma-compute): "AIs are great with CLIs. I just told Claude: this is the docs, install the CLI and use the CLI to do stuff." ## The port, step by step [#the-port-step-by-step] 1. **Declare each server.** Add the `service.ts` and `module.ts` above, plus the `composer` section in `prisma.config.ts` (the deploy config, with `entry: './module.ts'`) from the [deploy quickstart](https://www.prisma.io/docs/prisma-compute/deploy#bring-an-app-you-already-have). Then make the three changes to each Node.js or Bun server that [Port an existing app](https://www.prisma.io/docs/composer/porting-an-app#a-nodejs-or-bun-service) lists (a Next.js app uses the `nextjs` build adapter instead and follows the guide's [Next.js section](https://www.prisma.io/docs/composer/porting-an-app#a-nextjs-app)): 1. Read the port from `service.port()`, never `process.env`, and bind `0.0.0.0`. 2. Replace every other `process.env` read: config and credentials become fields of the service's input schema, and anything another service provides becomes a dependency. 3. If the server talks to Postgres, declare the database as a dependency and build your existing client from the injected `db.url` instead of a connection-string variable. The build must produce a self-contained entry file; `bun build --target=bun` does if yours does not. 2. **Run it locally.** `npm run build`, then `npx prisma dev`; every service starts with a local URL and a local Postgres. 3. **Deploy once from your machine.** `npx prisma deploy` creates the project, and a new project needs a region, set once in the deploy config or the environment. The deploy does not link the directory to the project, so then run `npx prisma project link my-app` in the project root, next to `module.ts`; `git connect` operates on the linked project. 4. **Connect the repository.** `npx prisma git connect https://github.com/you/my-app` installs the Prisma GitHub App and registers the repository. Connecting deploys nothing; it lets workflow runs authenticate and subscribes the project to branch events. 5. **Add the deploy workflow.** Commit this file: ```yaml title=".github/workflows/prisma-deploy.yml" name: prisma-deploy on: push: concurrency: group: prisma-deploy-${{ github.ref }} cancel-in-progress: false permissions: contents: read id-token: write jobs: deploy: if: github.ref_type == 'branch' runs-on: ubuntu-latest steps: - uses: actions/checkout@v4 - uses: actions/setup-node@v4 with: node-version: 22 - uses: oven-sh/setup-bun@v2 - uses: prisma/cloud-deploy-action@v1 with: build-command: npm run build ``` `id-token: write` lets the job exchange GitHub's OIDC token for a 30-minute Prisma workspace token, so the repository holds no Prisma credential; from an unconnected repository the action sets its `outcome` to `skipped-no-credential` and the run stays green. 6. **Push.** The default branch deploys production; any other branch deploys a preview named after it, with its own services, databases and URL, torn down when the branch is deleted. In your code, the frontend calls the API's contract instead of a URL (a contract endpoint returns `401` to browsers, so browser-side calls move into a Next.js page or server action), the server reads port and config from the service, and the runtime is Bun. Existing data does not move: the deploy provisions a new database and copies no data into it. Two runtime properties shape the code as well. A request has 60 seconds to send its first byte, and streaming continues after that. Compute scales to zero and closes idle database connections, so keep the pool small and able to reconnect. [Composer limitations](https://www.prisma.io/docs/composer/limitations) lists what the framework does not do yet. ## Where Prisma is the wrong choice [#where-prisma-is-the-wrong-choice] * **Your API holds WebSocket connections open, or streams to other services.** Compute does not run WebSocket servers today (support is planned for early 2027), and Composer contracts are RPC over HTTP with no streaming; use Railway, Render or Fly.io. * **You are not writing TypeScript.** Compute runs TypeScript services built for Node.js, Bun or Next.js, not Python or Go; deployed apps run on Bun. A Python or Go API belongs on Railway, Render, Fly.io or a VPS. * **You need more than one region.** Each Compute service runs in one of six regions; Fly.io places Machines where you choose, while a Fly.io Managed Postgres cluster sits in one region. * **You want to run your own Docker image.** Compute deploys the built output of Composer's `node` or `nextjs` adapter rather than an image you supply; Railway, Render and Fly.io run a container you build. * **Your frontend needs a global CDN above all.** Prisma Compute is not a CDN or edge platform, so put the frontend on Vercel and keep the database on Prisma Postgres. * **Your database needs point-in-time recovery today.** Prisma Postgres has daily snapshots on paid plans and no point-in-time recovery yet (coming in November 2026); [Just the database](#just-the-database-prisma-postgres-neon-or-supabase) names the databases that have it. * **You want the platform to run the build.** Prisma's deploys run in your GitHub Actions; Railway and Render build on their own machines. * **Your code is not on GitHub.** Deploy on push is GitHub only; other CI can run `npx prisma deploy` with a service token, but you script stages and teardown yourself. * **You want the lowest bill and will run servers yourself.** Past the free tiers, a VPS you patch yourself is the lowest monthly bill here; backups, upgrades and uptime are on you. ## Frequently asked questions [#frequently-asked-questions] ### How does a push to GitHub deploy on Prisma? [#does-connecting-a-github-repository-to-prisma-deploy-it] After the first deploy, link the directory with `npx prisma project link `, run `npx prisma git connect` and commit a GitHub Actions workflow that runs `prisma/cloud-deploy-action`, or connect in the Console, which opens a pull request that adds the workflow. Once the workflow is in the repository, a push to the default branch deploys production, and any other pushed branch gets a preview with its own services and, for databases declared in the Composer module, its own new database; production data is not copied ([deploy on push](https://www.prisma.io/docs/compute/deploy-on-push), [the git command](https://www.prisma.io/docs/cli/git), [the project command](https://www.prisma.io/docs/cli/project)). The connection lets the workflow's runs authenticate; without the workflow, connecting deploys nothing. ### Do I need to switch to Prisma ORM? [#do-i-need-to-switch-to-prisma-orm] No, you keep the client you have. `rawPostgres()` gives your service the connection string, and `pg`, Drizzle or any other Postgres client builds from it, with migrations run as today. The typed client and deploy-applied migrations are the `postgres()` path, which needs Prisma ORM 8. ### Does every preview branch get its own database on Prisma? [#does-every-preview-branch-get-its-own-database-on-prisma] Once deploy on push is set up, yes: every pushed branch other than the default one gets a preview with its own services and, for databases declared in the Composer module, its own new database; production data is not copied. The preview is named after the branch and deploys whether or not the branch has a pull request. On the `postgres()` path the deploy applies your committed migrations, and on `rawPostgres()` you run your own. If the app reads its connection string from a variable such as `DATABASE_URL` instead, the preview is only as separate as that value, so set a preview-scoped `DATABASE_URL` that points at a non-production database ([deploy on push](https://www.prisma.io/docs/compute/deploy-on-push)). For a small form API, [hosting Next.js form submissions](https://www.prisma.io/compute/nextjs-form-submissions) narrows the choice to running the POST handler, saving the accepted record and handling retries and notifications. ## Sources [#sources] * Prisma: [Deploy on push](https://www.prisma.io/docs/compute/deploy-on-push), [Known limitations](https://www.prisma.io/docs/compute/limitations), [Compute pricing](https://www.prisma.io/docs/compute/pricing), [Backups](https://www.prisma.io/docs/postgres/database/backups), [Port an existing app](https://www.prisma.io/docs/composer/porting-an-app), [Composer databases](https://www.prisma.io/docs/composer/databases), [the deploy command](https://www.prisma.io/docs/cli/deploy), [the project command](https://www.prisma.io/docs/cli/project), [the git command](https://www.prisma.io/docs/cli/git) and [Build a marketing site with Astro](https://www.prisma.io/docs/guides/compute/astro-marketing-site). * Railway: [pricing](https://railway.com/pricing), [environments](https://docs.railway.com/environments), [PostgreSQL](https://docs.railway.com/databases/postgresql), [what Railway manages](https://docs.railway.com/databases#what-railway-manages), [backups](https://docs.railway.com/volumes/backups), [point-in-time recovery](https://docs.railway.com/volumes/point-in-time-recovery), [Railpack](https://docs.railway.com/builds/railpack), [Dockerfiles](https://docs.railway.com/builds/dockerfiles), [services](https://docs.railway.com/services), [GitHub autodeploys](https://docs.railway.com/deployments/github-autodeploys), [variables](https://docs.railway.com/variables) and [SSE vs WebSockets](https://railway.com/guides/sse-vs-websockets). * Render: [pricing](https://render.com/pricing), [preview environments](https://render.com/docs/preview-environments), [Blueprint YAML reference](https://render.com/docs/blueprint-spec), [connection pooling](https://render.com/docs/postgresql-connection-pooling), [free instances](https://render.com/docs/free), [deploys](https://render.com/docs/deploys), [Git provider deploys](https://render.com/docs/git-provider), [creating and connecting to Postgres](https://render.com/docs/postgresql-creating-connecting), [Postgres recovery and backups](https://render.com/docs/postgresql-backups) and [supported languages](https://render.com/docs/language-support). * Fly.io: [pricing](https://docs.fly.io/about/pricing/), [free waiver](https://docs.fly.io/about/free-waiver/), [Managed Postgres](https://docs.fly.io/postgres), [creating a Managed Postgres cluster](https://docs.fly.io/postgres/create-and-connect/), [legacy unmanaged Fly Postgres](https://docs.fly.io/unmanaged-postgres/), [the `fly postgres` command](https://docs.fly.io/flyctl/cmd/fly_postgres/), [scaling Machine count](https://docs.fly.io/launch/scale-count/), [Fly Launch](https://docs.fly.io/launch/create/) and [review apps](https://docs.fly.io/blueprints/review-apps-guide/). * Vercel: [pricing](https://vercel.com/pricing), [Pro plan](https://vercel.com/docs/plans/pro-plan), [fluid compute pricing](https://vercel.com/docs/functions/usage-and-pricing), [Git deployments](https://vercel.com/docs/git), [CDN](https://vercel.com/docs/cdn), [Express on Vercel](https://vercel.com/docs/frameworks/backend/express), [Prisma Postgres on the Marketplace](https://vercel.com/marketplace/prisma), [WebSockets](https://vercel.com/docs/functions/websockets) and [WebSocket support is now generally available](https://vercel.com/changelog/websocket-support-is-now-generally-available). * Neon: [instant restore](https://neon.com/docs/postgres/backup-restore/branch-restore). Supabase: [database backups](https://supabase.com/docs/guides/platform/backups). The Railway, Render, Fly.io and Vercel pages were checked on 2026-09-30, their build, preview and database facts used in this post were checked again on 2026-10-08, and Railway's pricing and Fly.io's pricing, Fly Launch and Managed Postgres pages were checked again on 2026-10-14; Railway's pricing and free trial and Render's free-instance page were checked again on 2026-10-21. Railway's Railpack, Dockerfile, PostgreSQL, environments, services, GitHub autodeploy and variables pages, Render's free-instance, pricing, deploys, Git provider, Postgres connection and preview environment pages, Fly.io's pricing, Managed Postgres cluster and Machine scaling pages and Vercel's Prisma Postgres Marketplace listing, WebSockets page and WebSocket changelog entry were checked again on 2026-10-24, and Render's preview environment and Blueprint reference pages again on 2026-10-25. Fly.io's pricing, Managed Postgres and Managed Postgres cluster pages were checked again on 2026-11-06. Railway's Railpack page was checked again on 2026-11-09, as were Railway's databases page, Render's free-instance page and Fly.io's Managed Postgres, legacy unmanaged Postgres and `fly postgres` command pages. Fly.io's pricing, free waiver and Managed Postgres pages and Render's preview environment page were checked again on 2026-11-12. The Neon and Supabase pages were checked on 2026-10-07, and Neon's instant restore and Supabase's database backups pages again on 2026-11-06. They change often. ## Update history [#update-history] * 2026-11-12: said in the situation table and the Fly.io pricing line that Fly.io, which still has no free tier, waives a personal organization's monthly bill under $5 once a credit card is on file, in the pricing line that a bill of $5 or more is charged in full and other organizations get no waiver, and in the situation table that Fly.io's Managed Postgres starts at $38 a month; said in the Render entry and its comparison with Prisma Compute that preview environments need a Pro workspace or higher and stay off until the Blueprint sets `previews.generation` to `manual` or `automatic`. Fly.io's pricing, free waiver and Managed Postgres pages and Render's preview environment page were checked on 2026-11-12. * 2026-11-09: dropped the module file from the `npx prisma deploy` and `npx prisma dev` commands, because the current CLI takes no positional argument and reads the entry from the `composer` section of `prisma.config.ts` (`entry: './module.ts'`), which the setup steps now name; said in the Render trade-offs that a free web service spins down after 15 minutes without traffic and takes about a minute to start again, while a free Postgres database does not spin down and expires 30 days after creation; said in the Fly.io trade-offs that the older `fly postgres` commands manage the legacy Fly Postgres app, which Fly.io no longer maintains or supports; and pointed the "What Railway manages" links back at Railway's databases page, because the docs source on GitHub returns 404. Prisma's deploy and dev command docs, error reference and porting guide, Railway's databases page, Render's free-instance page and Fly.io's Managed Postgres, archived Fly Postgres and `fly postgres` command pages were checked on 2026-11-09. * 2026-11-09: moved the note on Railway's zero-configuration builds for supported languages from the first row of the situation table into the Railway comparison with Prisma Compute, where the same Railpack fact already sat; the first row now ends with the deploy-on-push steps. Railway's Railpack page was checked on 2026-11-09. * 2026-11-06: said in the quick recommendation that Prisma Compute has been generally available since August 2026; replaced the Fly.io trial in its pricing line with Fly.io's current one, $1 of credit for Machines, Sprites and Managed Postgres that lasts 7 days or until it is used up, with no credit card needed, and still no free tier; dropped the Small compute requirement from Supabase's point-in-time recovery add-on in "Just the database", because Supabase's docs now offer it on all compute sizes; and said in the Fly.io comparison with Prisma Compute that the Managed Postgres cluster runs in one region you choose, while the app's Machines can run in several. Fly.io's pricing, Managed Postgres and Managed Postgres cluster pages, Supabase's database backups page and Neon's instant restore page were checked on 2026-11-06. * 2026-11-02: listed Prisma Postgres first among the Vercel Marketplace databases in the opening, in line with the platform order in the same sentence. No facts changed. * 2026-10-31: said in the second paragraph that your coding agent can add the Prisma Composer declaration and make the three server changes, and show you the diff, and named the previewed branches in the small production app row of the situation table: each pushed branch other than the default. Prisma's porting guide and deploy-on-push docs were checked on 2026-10-30. * 2026-10-29: said in the Prisma Compute trade-offs and in "Where Prisma is the wrong choice" that WebSocket server support on Prisma Compute is planned for early 2027, and in "Can I host my existing GitHub repo on Prisma?" that every deploy needs a Composer declaration today and that deploying an existing repository without a Composer file is planned for early 2027. Prisma's Compute limitations page and Compute FAQ were checked on 2026-10-29. * 2026-10-28: added a first row to the situation table for an existing GitHub repository with a TypeScript frontend and a Node API, with the coding-agent port, the deploy command with its region and the deploy-on-push setup, and Railway's zero-configuration builds for supported languages; opened "Just the database" with Prisma Postgres for a frontend on Vercel or Netlify and an API on Railway or Render, and renamed that section; and retitled the GitHub question to how a push deploys, leading with the link, connect and workflow steps. Prisma's deploy-on-push, git, project and deploy command docs, the porting guide, prisma.io/pricing, the Prisma Postgres docs and Railway's Railpack page were checked on 2026-10-28. * 2026-10-27: said in the situation table and in the Railway, Render and Fly.io comparisons with Prisma Compute that a preview is for each pushed branch other than the default one, and in the situation table that a push to the default branch deploys production. Prisma's deploy-on-push docs were checked on 2026-10-27. * 2026-10-26: said in the quick recommendation that Prisma Compute with Prisma Postgres gives one provider, one project and one bill for the frontend, the API and the database, and opened the first Prisma step in "Steps from repo to running app" with the porting guide's prompt for a coding agent, keeping the manual changes as the alternative. Prisma's pricing page, the Compute FAQ and the porting guide were checked on 2026-10-26. * 2026-10-25: added the `npx prisma project link` step between the first deploy and `npx prisma git connect`, in "Steps from repo to running app" and in "The port, step by step", because the deploy does not link the directory and `git connect` needs a linked project; and said in the Render preview step to define the web service and database in a `render.yaml` Blueprint and set `DATABASE_URL` with a `fromDatabase` reference instead of a pasted production URL. Prisma's deploy-on-push and project command docs and Render's preview environment and Blueprint reference pages were checked on 2026-10-25. * 2026-10-24: added "Steps from repo to running app" with the deploy steps for Prisma Compute with Prisma Postgres, Railway and Render, from creating the service from the GitHub repository and setting its database URL to running migrations; opened the second paragraph with the one-command deploy; added a situation row for a Vite or React single-page app with a Node API, whose built files your own Node.js or Bun server serves; named Prisma Postgres, Neon and Supabase as Marketplace databases in the Vercel section; said that new Fly.io organizations get a trial, not a free tier, and that a Fly.io Managed Postgres cluster sits in one region while Machines can run in several; said that a free Render web service takes about a minute to spin back up; and said that WebSocket support in Vercel Functions is generally available since 2026-10-20, no longer in beta. Railway's Railpack, Dockerfile, PostgreSQL, environments, services, GitHub autodeploy and variables pages, Render's free-instance, pricing, deploys, Git provider, Postgres connection and preview environment pages, Fly.io's pricing, Managed Postgres cluster and Machine scaling pages, Vercel's Prisma Postgres Marketplace listing, WebSockets page and changelog, and Prisma's Compute, Composer and deploy command docs were checked on 2026-10-24. * 2026-10-22: point-in-time recovery for Prisma Postgres now has a date, November 2026, wherever this post says it is not available yet; until then, paid plans keep daily snapshots. No other facts changed. * 2026-10-22: pointed the "What Railway manages" links at that table in Railway's docs source, because Railway's databases overview page returns 404; the Railway statements are unchanged and were checked against the table on 2026-10-22. * 2026-10-21: added two rows to the top of the situation table, one for a frontend and Node API from one repository on the Free plan, with its Compute and Prisma Postgres limits from prisma.io/pricing and one link to the Compute FAQ answer on existing repositories, and one for a side project that should stay at $0, with what happens when the Free operations run out, including the one-time 24-hour grace period, and the free plans of Render and Railway; dropped the Composer declaration step from the deploy-from-GitHub row, since the new first row covers it; used the same trial wording in the Railway pricing line; put Prisma Compute first in the comparison heading, matching the order of the sections below it; said in the Prisma Compute "Best for" line that neither product needs Prisma ORM; and said under "Where Prisma is the wrong choice" that Prisma Compute is not a CDN or edge platform. Railway's pricing and free trial, Render's free-instance page and prisma.io/pricing were checked on 2026-10-21. * 2026-10-14: linked the Compute FAQ answer on existing repositories and this post's list of server changes once instead of repeating the porting steps in each platform's comparison, said in the quick recommendation that neither product needs Prisma ORM, added Railway's Free plan ($0 with $1 of credit a month after a 30-day trial with $5 of credit) to its pricing line, replaced "the most to operate of the five" in the Fly.io trade-offs with the Dockerfile and `fly.toml` you keep in the repository, which `fly launch` generates for most frameworks, said that Fly.io runs Managed Postgres (`fly mpg`), and moved the Railway and Fly.io pricing lines to October 2026, checked against railway.com/pricing and Fly.io's pricing, Fly Launch and Managed Postgres docs on 2026-10-14. * 2026-10-08: opened with the five platforms side by side, listed the three server changes a port needs, moved the cases for other platforms into one table row and "Where Prisma is the wrong choice", ended each competitor section with how it compares with Prisma Compute for this repository, noted that Railway maintains its Postgres template, changed the deploy config to the `composer` section of `prisma.config.ts`, and said in the opening that the app and the database run in one project, with the Free and Starter pricing as its own sentence. * 2026-10-07: answered the existing-repository question in the opening with the files you add and the client you keep, added a database-only row and a "Just the database" section for apps that stay on another host, kept the cases for other platforms in "Where Prisma is the wrong choice" instead of repeating them, shortened the meta title and dropped the Free plan storage figure. * 2026-10-05: linked the managed Postgres platform comparison from the Fly.io entry, pointed the limits link at the trade-offs list in the Compute FAQ, noted that Railway PR environments are a project setting, and updated Railway, Render and Fly.io links to their current paths. * 2026-09-30: rewrote the recommendation as a situation table with existing-repository rows first, added Vercel, moved the port below the table, re-checked vendor prices and docs. * 2026-09-22: first published.