diff --git a/apps/blog/content/blog/choosing-hosting-and-postgres-after-your-first-100-users/index.mdx b/apps/blog/content/blog/choosing-hosting-and-postgres-after-your-first-100-users/index.mdx index 5475619167..143a93ad3f 100644 --- a/apps/blog/content/blog/choosing-hosting-and-postgres-after-your-first-100-users/index.mdx +++ b/apps/blog/content/blog/choosing-hosting-and-postgres-after-your-first-100-users/index.mdx @@ -2,7 +2,7 @@ title: "Hosting and managed Postgres options for your startup's first 100 paying users (2026)" slug: "choosing-hosting-and-postgres-after-your-first-100-users" date: "2026-09-24" -updatedAt: "2026-10-14" +updatedAt: "2026-10-21" authors: - "Gregory Boch" metaTitle: "Hosting and managed Postgres options for a startup's first 100 paying users (2026)" @@ -339,8 +339,17 @@ cached reads can be out of date, so leave permission checks and balances uncache [pricing page](https://www.prisma.io/pricing) and [deploy on push](https://www.prisma.io/docs/compute/deploy-on-push), checked 2026-10-08. +## Related guides + +If you are still deciding how to persist the prototype's records, start with [hosted Postgres for customer data](https://www.prisma.io/postgres/prototype-customer-data). For records that mix stable fields and changing attributes, see the [customer records and JSONB example](https://www.prisma.io/postgres/customer-records-json). + +For the person who will operate the app after launch, the [business app operations guide](https://www.prisma.io/compute/business-app-operations) covers account ownership, live-version checks and rehearsed recovery. + ## Update history +- 2026-10-21: the links to the guides on customer data, customer records and business app + operations, added on 2026-10-17 and 2026-10-20, moved from below this history to a Related + guides section. - 2026-10-14: the opening and the any-language recommendation say that Prisma Postgres works from any language through any Postgres client, and the quick recommendation and the point-in-time recovery row say that Supabase's point-in-time recovery is a paid add-on. @@ -375,7 +384,3 @@ cached reads can be out of date, so leave permission checks and balances uncache dated Railway, Render, Neon and Supabase prices, the Compute line example, a FAQ, "How we compared", Sources and this history. - 2026-09-24: first published. - -If you are still deciding how to persist the prototype's records, start with [hosted Postgres for customer data](https://www.prisma.io/postgres/prototype-customer-data). For records that mix stable fields and changing attributes, see the [customer records and JSONB example](https://www.prisma.io/postgres/customer-records-json). - -For the person who will operate the app after launch, the [business app operations guide](https://www.prisma.io/compute/business-app-operations) covers account ownership, live-version checks and rehearsed recovery. diff --git a/apps/blog/content/blog/host-a-test-version-without-replacing-production/index.mdx b/apps/blog/content/blog/host-a-test-version-without-replacing-production/index.mdx index 821036e8bc..eb88354cbf 100644 --- a/apps/blog/content/blog/host-a-test-version-without-replacing-production/index.mdx +++ b/apps/blog/content/blog/host-a-test-version-without-replacing-production/index.mdx @@ -2,11 +2,11 @@ title: "How to host a test version of your app without replacing production (2026)" slug: "host-a-test-version-without-replacing-production" date: "2026-10-15" -updatedAt: "2026-10-19" +updatedAt: "2026-10-21" authors: - "Gregory Boch" metaTitle: "How to host a test version of your app without replacing production (2026)" -metaDescription: "Deploy the new version from a Git branch to a preview or staging environment with its own URL and test database; only the main branch deploys production." +metaDescription: "Deploy a branch to a preview or staging URL with a test database; only main deploys production. How Fly.io, Netlify, Prisma Compute, Railway, Render and Vercel do it." heroImagePath: "/host-a-test-version-without-replacing-production/imgs/hero.svg" heroImageAlt: "Two lanes side by side: the main branch deploys production, which customers use with the production database, while a feature branch deploys a preview at its own URL with its own test database; merging the pull request releases the change to production." metaImagePath: "/host-a-test-version-without-replacing-production/imgs/meta.png" @@ -17,7 +17,7 @@ tags: - "ai" --- -To host a test version without replacing the one customers use, deploy the new code from its own Git branch to a separate preview or staging environment with its own URL, its own environment variables and its own test database, and let only your main branch deploy to production. Test the change on that URL, and when it works, merge the pull request so the normal production deploy releases it. If a coding assistant is writing the feature, the same setup applies: it works on a branch, opens a pull request, and you check the preview before you merge. +To host a test version without replacing the one customers use, deploy the new code from its own Git branch to a separate preview or staging environment with its own URL, its own environment variables and its own test database, and let only your main branch deploy to production. Test the change on that URL, and when it works, merge the pull request so the normal production deploy releases it. Fly.io, Netlify, Prisma Compute, Railway, Render and Vercel can each deploy a branch or pull request as a preview, on some hosts only after you turn previews on, add a workflow or move to a paid plan; see [How to do it on common hosts](#how-to-do-it-on-common-hosts). If a coding assistant is writing the feature, the same setup applies: it works on a branch, opens a pull request, and you check the preview before you merge. :::note[About this guide] This guide is published on Prisma's blog. We make Prisma Compute and Prisma Postgres; together they are one of the six hosts in [How to do it on common hosts](#how-to-do-it-on-common-hosts). The hosts are listed in alphabetical order, and every vendor detail comes from that vendor's own docs, checked on 2026-10-15 and linked under [Sources](#sources-checked-2026-10-15). The patterns themselves work on any host. @@ -191,3 +191,4 @@ Make production deploy only from the main branch, protect that branch in GitHub - 2026-10-16: added that GitHub branch protection in a private repository needs a paid plan, and that a pull request GitHub Copilot opens for you needs a second approver, checked against GitHub's docs on 2026-10-16; step 4 now says previews have to be set up on the host first. - 2026-10-16: added a video walkthrough of the workflow on Prisma Compute and Prisma Postgres. - 2026-10-19: the Render staging line now says blocking private network traffic between environments needs a Pro workspace or higher, checked against Render's pricing page on 2026-10-19. +- 2026-10-21: the opening answer and the meta description name the six hosts the guide covers: Fly.io, Netlify, Prisma Compute, Railway, Render and Vercel. diff --git a/apps/docs/content/docs/compute/deploy-on-push.mdx b/apps/docs/content/docs/compute/deploy-on-push.mdx index 7952713801..100fb20b88 100644 --- a/apps/docs/content/docs/compute/deploy-on-push.mdx +++ b/apps/docs/content/docs/compute/deploy-on-push.mdx @@ -31,6 +31,10 @@ npx prisma project env add API_BASE_URL=https://staging-api.example.com --branch When a release is ready, merge `staging` into the default branch, and that push updates production. On Compute, the staging services cost money only while they do work, such as serving traffic, because creating a preview branch is free and an idle app scales to zero; see [Compute pricing](/compute/pricing#what-is-not-billed-separately). Without GitHub, `npx prisma deploy module.ts --stage staging` deploys the same kind of persistent staging environment from your terminal or another CI system, as [Deploying](/composer/deploying#production-and-stages) shows. +### Coming from Vercel or Netlify previews + +Vercel deploys a preview for every push to a branch other than the production branch, and Netlify builds a Deploy Preview by default for each pull request in a connected repository whose base branch is a production branch or has branch deploys enabled, unless Deploy Previews are turned off; here, each pushed branch other than the default one gets a preview with every service your module declares. Vercel's Preview environment variables and their branch-specific values map to preview-scoped values and branch overrides. The database differs from Netlify Database, whose deploy previews start with a copy of the production data: here each Prisma Postgres database your module declares is created new for the branch and production data is not copied, so seed the data you test with. For apps that read `DATABASE_URL`, see **Its own databases** above. [How to host a test version of your app without replacing production](https://www.prisma.io/blog/host-a-test-version-without-replacing-production) compares the same workflow on Fly.io, Netlify, Prisma Compute, Railway, Render and Vercel. + ## If a coding assistant is building the feature Have the assistant (Claude Code, Codex, Cursor or another coding agent) work on a feature branch and push that branch, not the default one. With the workflow from this guide in the repository, 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. If the app reads `DATABASE_URL`, the preview is only as separate as that value, so give previews a preview-scoped `DATABASE_URL`.