Preview environments with a real database per pull request
If you ask ten developers what a “preview environment” is, you will get a spectrum of answers. On one end: a static frontend bundle pointing at production. On the other: a full copy of the stack with its own isolated database. The difference matters more than it sounds.
The shared-database trap
When every branch points at the same database, you run into a set of problems that compound as the team grows:
- Destructive migrations from one branch affect every other open PR
- Test data conflicts — one reviewer creates a user, another reviewer's test flow collides
- No safe way to reproduce production bugs on realistic data
- QA cannot set up scenarios because anyone else's push can invalidate them
Most teams eventually hack around this with a combination of feature flags, tenant scoping in dev data, and polite Slack messages. That is not a great long-term plan.
What per-branch databases unlock
A preview environment with its own database looks different. Suddenly you can:
- Run a destructive migration on one branch without affecting any others
- Seed a branch with production-like data for realistic QA
- Leave test users, feature flags, and state intact for a reviewer to come back to
- Reproduce a customer's bug on their exact seed and hand the URL around the team
The interesting catch: you want the database to survive subsequent pushes on the same branch. If every push resets the database, the feature becomes useless because your test setup is wiped every time you fix a typo.
Incremental deploys
The right pattern is: the first push to a branch provisions a fresh database, any configured addons, and the app container. Every subsequent push rebuilds only the app container — the database keeps all its state. The result is a fast feedback loop that preserves context between pushes.
When you do want a clean slate, a single “reset database” action re-provisions from scratch. It is opt-in, not the default, so you stay in control.
How Nexos implements this
Every Nexos environment can have Postgres and Redis addons enabled. On the first push to a branch, those containers are provisioned alongside the app. On every subsequent push only the app container rebuilds. The result is preview environments that actually behave like a developer expects a preview to behave.