Previews

A preview is a temporary environment for testing a change, usually one per branch or pull request. It starts with a copy of another environment’s definitions (tables, rules, flows, templates…), has its own empty data, comes with its own keys, and removes itself when it expires.

Why use previews

Test a change with real tables and rules without touching staging.
Give a reviewer a working backend for a pull request’s preview deployment.
Run automated tests against a clean environment every time.
Try a risky migration somewhere disposable first.

Create one in Studio

Project → Environments → New preview.
Choose the environment to copy from (usually development or staging).
Give the ref: lowercase letters, digits and dashes, up to 48 characters, typically the branch name (add-referrals). The preview is called pr-<ref> unless you give it a name.
Choose how long it lives: 72 hours by default, from 1 hour to 30 days.
Create. Studio shows its publishable and secret keys. Copy them now.

What a preview contains

Copied from the source	Not copied
Definitions: tables (created empty), rules, schemas, flows, routes, subscriptions, schedules, webhooks, inbound hooks, buckets, mail templates, knowledge bases, connections and agents	Data: no rows, files, users or sign-in history
The source’s settings (you can override some)	Secrets: add the ones its flows and connections need
	API keys: the preview gets its own
	Its public API reference is switched off

Its two keys, a publishable key and a secret key, expire when the preview does.

Copied webhooks and schedules are live in the preview. If a webhook points at a real partner, or a schedule sends email, disable them in the preview or point them at test targets. Pause mail delivery in previews.

Create one from CI

The usual setup: when a pull request opens, CI creates a preview, seeds it, deploys the frontend preview against it, runs tests, and the preview expires on its own.

import { createClient } from "@pawabase/client";
import { manage } from "@pawabase/client/manage";

const pawabase = createClient({ url: process.env.PAWABASE_URL!, apiKey: process.env.PAWABASE_SECRET_KEY!, environment: "staging" });
const preview = await manage(pawabase).environments.createPreview(process.env.BRANCH_SLUG!, { expiresInHours: 48 });
// preview.name, and preview.keys.publishable / preview.keys.secret for the preview deployment

curl -X POST "$PAWABASE_URL/platform/v1/envs/staging/previews" \
  -H "apikey: $PAWABASE_SECRET_KEY" -H "content-type: application/json" \
  -d "{\"ref\": \"$BRANCH_SLUG\", \"expires_in_hours\": 48}"

The request takes:

Field	Meaning	Default
`ref`	Branch or pull request ref: lowercase letters, digits and dashes, up to 48 characters	required
`name`	The environment’s name	`pr-<ref>`
`expires_in_hours`	1 to 720	72
`settings`	Settings to override, merged over the source’s	none
`auth`	Sign-in settings for the preview	none

The source environment is the one in the address (/envs/staging/previews), and the key used must be allowed to manage it. A preview with the same name already existing is refused with 409, so use a stable ref per pull request and delete or reuse it. If your plan’s environment limit is reached, creating a preview is refused. Infrastructure as code can then deploy the branch’s own definitions to the preview, so it matches the branch rather than the source.

Seed it

A preview’s tables start empty. Seed what your tests need from CI, using the preview’s secret key:

const preview = createClient({ url: process.env.PAWABASE_URL!, apiKey: previewSecretKey, environment: previewName });
await preview.from("products").create({ title: "Test mug", price: 12 });

Or keep a seed backup file with only data, and restore it into the preview.

Clean up

A preview expires by itself: when its time is up, it and everything in it are removed. To remove it sooner (for example when the pull request closes), delete it from Project → Environments, or:

curl -X DELETE "$PAWABASE_URL/platform/v1/envs/staging/previews/pr-add-referrals" -H "apikey: $PAWABASE_SECRET_KEY"

Deleting removes its data, keys, secrets and users for good.

Good practice

Name previews after the branch, so it’s obvious which can go.
Use test keys for any provider a preview’s flows call. Never a live payment key.
Disable outbound webhooks in previews unless they point at test receivers.
Never put real customer data in a preview.
Keep the lifetime short and let CI recreate it.

Environments

Activity

Secrets and backups

Pawabase Cloud

Why use previews

Create one in Studio

What a preview contains

Create one from CI

Seed it

Clean up

Good practice

​Why use previews

​Create one in Studio

​What a preview contains

​Create one from CI

​Seed it

​Clean up

​Good practice

Why use previews

Create one in Studio

What a preview contains

Create one from CI

Seed it

Clean up

Good practice