From development to production

You’ll set up a release process that lets you build freely and ship safely: work in development, check in staging (and in a preview per pull request), and move to production with a review of exactly what changes, a backup first, and a way back. You’ll use: environments, API keys, previews, promote, backups.

The setup

Environment	Who uses it	Keys in	Data
`development`	You, building in Studio	Your laptop’s `.env`	Made-up
`pr-<branch>` previews	CI, reviewers	The preview deployment	Seeded test data
`staging`	QA, demos	The staging deployment	Test data, or anonymised copies
`production`	Customers	The production deployment’s secret store	Real

1. Create the environments

Project → Environments → New environment: staging, copying from development; then production, copying from staging. Each comes with its own publishable and secret keys, shown once: store them in each deployment’s secret store. Make production the default environment if you want requests that name no environment to go there.

2. Point each app at its environment

export const pawabase = createClient({
  url: import.meta.env.VITE_PAWABASE_URL,
  apiKey: import.meta.env.VITE_PAWABASE_PUBLISHABLE_KEY,
  environment: import.meta.env.VITE_PAWABASE_ENVIRONMENT,   // development | staging | production
});

A key only works with its own environment, so a staging key in a production build fails loudly instead of silently mixing data.

3. Things promote doesn’t copy

Set these up in each environment by hand, once:

Thing	Where
Secrets (payment keys, partner tokens)	Secrets; test values in development, live in production
Mail delivery	Mail → Delivery; paused or a test inbox in development
AI providers and models	AI → Providers, AI → Models, with the same model names
Connection keys	AI → Connections
Sign-in providers, redirect URLs	Users & auth
Alarms, status page	Activity → Alarms, Status page

4. A preview per pull request

In CI, when a pull request opens, create a preview from staging and give its keys to the preview deployment. It expires by itself. See Previews.

5. Release: review, back up, promote

Promote development → staging, with a review

Promote from development to staging. The dry run lists added and changed definitions, the table changes that will be applied, those that need review (renames, type changes, removals, which promote never applies), and anything blocked.

Test staging

Run your end-to-end tests and the rule tests from Testing rules.

Back up production

Backups → Back up now, named after the release, and pin it.

Promote staging → production

Review the dry run again: it should be what you saw in staging.

Watch

For the next hour, watch Activity → Overview and Errors, and compare with before.

In code, with a secret key that can manage both environments:

const m = manage(pawabase, "staging");
const review = await m.environments.promote("production", { dryRun: true });
if (review.blocked.length) throw new Error(review.blocked.join("\n"));
await manage(pawabase, "production").backups.snapshot(`release-${version}`);
await m.environments.promote("production");

6. Changes promote won’t make

Renames, type changes and removals are listed, not applied, so a release can never drop a column that holds real data. Do them deliberately:

Add the new column (promoted automatically).
Deploy app code that writes both old and new.
Copy existing values over (a flow, or the SQL editor after a backup).
Deploy code that reads only the new column.
Remove the old column in each environment, by hand, last.

See Migrations and history.

7. Rolling back

What went wrong	Roll back by
A rule or flow change	Promote the previous version from staging, or fix forward in production
An API shape change broke old apps	Serve the old shape as a versioned API
Data damaged	Restore the pinned backup’s Data part (merge or replace), which first saves the current state

Alternatively: everything as code

If you’d rather review changes in pull requests than in Studio, keep your definitions in your repository with infrastructure as code and deploy the same code to each environment from CI (CI/CD). The same rules apply: secrets, keys and data stay per environment.

Promote

What it copies and how.

Production readiness

Before you launch.

Welcome

Concepts

Quickstarts

Tutorials

From development to production

The setup

1. Create the environments

2. Point each app at its environment

3. Things promote doesn’t copy

4. A preview per pull request

5. Release: review, back up, promote

6. Changes promote won’t make

7. Rolling back

Alternatively: everything as code

Promote

Production readiness

​The setup

​1. Create the environments

​2. Point each app at its environment

​3. Things promote doesn’t copy

​4. A preview per pull request

​5. Release: review, back up, promote

​6. Changes promote won’t make

​7. Rolling back

​Alternatively: everything as code

Promote

Production readiness

The setup

1. Create the environments

2. Point each app at its environment

3. Things promote doesn’t copy

4. A preview per pull request

5. Release: review, back up, promote

6. Changes promote won’t make

7. Rolling back

Alternatively: everything as code