scribase
Guide

Give every pull request a preview database

A preview on Scribase is a full environment — database, auth, and storage — not just a database copy, so a reviewer sees real behavior without touching production. This guide creates a preview for a pull request with the scribase CLI, records its lineage and pull request, runs your migrations against it, and lets its TTL clean it up. Every command runs against the hosted /v1 API with SCRIBASE_API_URL and SCRIBASE_ACCESS_TOKEN set.

Published September 23, 20266 min read

1.Create a preview environment for the pull request

Create an environment of kind preview with sanitized data and a TTL in hours. The positional idempotency key makes a retried CI step safe: the same key never creates a second environment. The command returns an operation you can poll until it succeeds.

bash
# env create <org> <project> <env> <kind> <data-mode> <region> <idempotency-key> [ttl-hours]
$ scribase env create acme store pr-1487 preview sanitized us-east pr-1487-create 72
{"id":"op_01J…","kind":"create_environment","state":"pending","attempt_count":0}

$ scribase operation get acme op_01J…
{"id":"op_01J…","state":"succeeded","attempt_count":1}

2.Record the branch lineage and link the pull request

Register the preview as a branch of production so Scribase captures the merge base for schema diffs, then link it to the pull request so the preview URL shows up next to the review.

bash
$ scribase branch register acme store pr-1487 --base production
$ scribase branch pr acme store pr-1487 github acme/storefront 1487

3.Plan, then apply your migrations against the preview

Point scribase migrate at your migrations directory (files named 001_name.sql, with optional .down.sql pairs). Without --apply the server plans and lints only, so a blocking finding stops the change before anything runs; add --apply once the plan is clean. Nothing touches production.

bash
$ scribase migrate acme store pr-1487 --dir ./migrations
$ scribase migrate acme store pr-1487 --dir ./migrations --apply

$ scribase branch diff acme store production pr-1487

4.Let the TTL sweep it, or delete it when the pull request closes

Previews carry the TTL you set at creation and the operator reconcile loop sweeps them when it expires, so stale, credential-bearing environments never accumulate. To remove one as soon as the pull request closes, delete it from your CI close hook.

bash
$ scribase env delete acme store pr-1487 pr-1487-delete
{"id":"op_01J…","kind":"delete_environment","state":"pending","attempt_count":0}
FAQ

Common questions

Is a preview branch only a database branch?

No. A preview is a full environment that includes the database, auth, and storage together, so it reflects real application behavior instead of a database copy on its own.

Do I have to clean previews up by hand?

No. Every preview carries a TTL and is swept when it expires; you can also delete one explicitly with scribase env delete as soon as the pull request closes.

Can I extend a preview that is still in review?

Yes. POST /v1/organizations/{org}/projects/{project}/environments/{env}/renew extends its TTL without recreating it.

Ready to try it?

Start a free project and follow this guide against a real backend, or move an existing project in with a dry run first.