preview-environments
Browse all articles, tutorials, and guides about preview-environments
Posts
Per-Branch AI Endpoints: Isolating Model Spend Across Prod, Preview, and CI
When previews, CI, and production all call models with the same key, you cannot tell what a preview cost or notice a runaway test until the invoice. Because a Neon branch is its own deployment with a usage ledger that lives in the branch's Postgres, model spend is attributed and isolated per environment. I proved it: a CI branch spent tokens while production stayed flat.
Stop Standing Up an S3 Bucket Per Preview Environment
Giving every preview environment isolated file storage usually means provisioning a real bucket per environment: policies, IAM, lifecycle rules, credentials, and a teardown job that leaves orphans anyway. When the bucket rides the database branch, that whole apparatus disappears. Here is the difference, tested.
Object Storage That Branches With Your Database
Database branching gives you a throwaway copy of your rows. But your app also stores files in object storage, and those normally stay in one shared bucket. On Neon a branch forks the bucket too, so each branch gets its own copy of the files. I built a small files API to prove it.
The Everything-on-Your-Branch Architecture
For a decade "branch the database" has meant a copy of the schema and rows. But your app is also files, backend code, and model config. Neon now forks all of it on one branch: Postgres, object storage, functions, and the AI gateway, together and isolated. I branched a full-stack project to prove it.
Preview Environments That Include the Backend, Not Just the Frontend
Every PR gets a frontend preview URL. The backend is almost always one shared staging database, so previews quietly lie to you. On Neon a branch is the database, its data, and the functions together, so each PR can get a real isolated backend. Here is the workflow, tested end to end.