Preview environments

A preview environment is a throwaway, fully isolated copy of your site tied to a single git branch. Push a non-default branch and managed.dev provisions one automatically, seeds it from production, and hands you a live URL. Delete the branch and it’s gone. Previews are the unit of review on managed.dev.

How a preview gets created

When you git push managed <branch> and the branch isn’t your default and isn’t routed to staging or ignore, the platform creates a preview for it.

1. You push a branch — say feature/checkout.
2. managed.dev builds the commit and provisions a new environment.
3. The environment’s database and files are cloned from production.
4. You get a live preview URL once the deploy job finishes.

Each preview is independent: its own database, its own files, its own observability. Nothing you do in a preview can reach production data. See branch routes for how the push-to-preview mapping is decided.

The preview URL

Previews are reachable at a stable, disposable URL built from the site, branch, and a short hash:

Preview URL pattern

https://<site>-<branch>-<hash>.preview.managed.dev

For feature/checkout on acme-store, that’s something like https://acme-store-feature-checkout-a1b2c3.preview.managed.dev. The URL is stable for the life of the branch, so it’s safe to paste into a pull request, a ticket, or an email to a client.

A pull request on GitHub with a managed.dev status check showing “preview environment ready” linked to the live acme-store-feature-checkout preview URL.

What previews are for

• Code review. Reviewers click the URL in the PR and see the change running, not just a diff.
• QA. Run a test suite or manual pass against a real environment with production-shaped data.
• Client sign-off. Share a working URL for approval before anything touches production.
• Promote gate. Check the preview’s traces for errors before you promote it.

Visitor data and the PII hard-cut

Previews never show pre-clone visitor data

A preview’s database is cloned from production, so it can carry visitor data created before the clone. managed.dev raises a hard-cut floor at the preview’s creation time: its requests, logs, and traces only ever surface rows generated after the environment was created. Pre-clone rows are never exposed through a preview’s observability.

Sharing and password protection

Preview URLs are reachable by anyone who has the link, which is what makes them useful for sign-off. When a preview shouldn’t be public, turn on password protection for the environment — the same control available on production — so only people with the credentials can load it.

The environment settings panel for a preview environment in the dashboard, with the password-protection toggle enabled and a generated access password field.

Teardown

Previews are ephemeral by design. When you delete or close the branch, managed.dev tears the environment down — database, files, and hostname all released. You can also delete a preview manually from the dashboard or via DELETE /v1/sites/{id}/environments/{id} if you want to reclaim it before the branch goes away. Production and staging are never torn down this way; only previews are ephemeral.

Tip

Wire teardown into your PR workflow so closing a pull request removes its preview automatically — see the preview-environment-per-PR guide.

Next steps

Promote & roll backShip a reviewed preview to production, and roll back instantly if needed.

A preview environment per pull requestWire branch environments into CI so every PR gets a live, reviewable URL.

Branch routesDecide which branches become previews and which become staging or production.