Preview environments

Preview environments give every pull request its own live, isolated deployment:

https://pr-42--myshop-a1b2c3.pandastack.app

Open a PR → PandaStack builds the PR’s head commit and serves it at a unique URL. Push more commits → the preview updates. Close or merge the PR → the preview is cleaned up. Your production deployment is never touched.

Rolling out

Preview environments are launching in stages on paid plans. If you don’t see the option yet, it’s coming to your account soon — and per-PR database clones (“every PR gets its own database”) are next on the roadmap.

How it works

1. Enable “PR Previews” on the project (project settings — paid plans).
2. Open a pull request against the project’s deploy branch (the branch on the project settings, e.g. main). PRs against other branches don’t build previews.
3. PandaStack builds the PR head and serves it at pr-<PR number>--<project>-<id>.pandastack.app. The double dash separates the PR number from the project name — which is why project names can’t contain --.
4. Every new push to the PR (a “synchronize”) rebuilds the preview at the same URL.
5. When the PR is closed or merged, the preview stops serving immediately and everything it used — the running instance, its container image, and its built files — is deleted shortly after. Nothing lingers and nothing keeps billing.

Previews expire automatically after 7 days without a push even if the PR stays open — expired previews are torn down the same way.

A sticky status comment on the pull request tracks the preview through its life: building → ready (with the URL) → torn down. If a build fails, the comment says so and a new push retries.

Both project types get previews: static sites are served from the CDN, and container apps run as a full isolated instance of your server per PR — always on the smallest tier with scale-to-zero, regardless of what production runs on, so idle previews cost nothing.

Enabling previews

Turn previews on per project: project page → Settings → “PR preview environments”, or the one-click enable on the project’s Preview environments card. Paid plans only; Pro allows 10 concurrent previews per organization (Premium 25) — beyond that, new PRs wait until an older preview is torn down or expires.

What a preview is (and isn’t)

• A preview is a full build of the PR’s code, served exactly like a deploy — same buildpacks, same CDN, same gateway.
• It is not your production deployment: previews never appear in the project’s deployment history, can’t be rolled back to, and never change which build production serves.
• Preview URLs are public but unlisted: anyone with the link can open them, and they carry noindex headers plus a blocking robots.txt, so search engines stay away.

Previews use your project’s environment variables

In the current version a preview runs with the project’s configured env vars — including anything like DATABASE_URL. Treat preview links accordingly, and prefer non-production values in projects with previews enabled. Scoped preview-only env (and isolated per-PR database clones) are on the roadmap.

Pull requests from forks

Previews build only for branches in the same repository. Pull requests from forks are skipped — building a stranger’s code with your project’s configuration would be a security risk, so fork PRs never trigger a preview. This matches how other platforms treat fork PRs.

Costs

• Preview builds use your normal build minutes.
• Static previews are served from the CDN (no compute).
• Container previews run on the smallest instance with scale-to-zero — an idle preview uses no compute at all.
• Preview traffic counts toward your organization’s bandwidth like any other project traffic.

Coming next

• Preview database clones — each PR gets a disposable copy of your linked database, restored from the latest backup and deleted with the preview. Test migrations against real data without touching production.

Related

• Static sites · Container apps
• Environment variables & secrets
• Rollbacks — previews never appear as rollback targets