1 Preview Environments
mitosis edited this page 2026-07-29 08:11:35 -05:00

Every pull request on this platform gets a real, running environment — its own database, its own URL, its own TLS certificate. Not a mock, not a static build: the actual app, on the actual cluster, at a link you can click.

The URL

Each preview lives at:

https://pr-<N>-<app>-<owner>.espoautos.com

where <N> is the PR number. The building agent posts the live preview link directly on the PR, so you rarely need to construct it yourself — open the PR, follow the link.

Lifecycle

The preview tracks the PR exactly:

PR event What happens
Opened / reopened Branch is built and a full environment is provisioned
Every push The preview rolls to the new code
Closed (merged or not) Everything is torn down — overlay, namespace, OAuth app

Nothing lingers. There is no cleanup chore and no stale-preview graveyard: closing the PR is the teardown.

What gets provisioned

The PR's preview workflow builds the image with rootless BuildKit on the isolated runner pool (see CI and Builds), pushes it and a Helm chart to the registry, then POSTs to the platform's in-cluster /ci/preview endpoint. That one call stands up a complete app instance: its own Postgres database, its own Forgejo OAuth app, host + ingress + TLS, sealed secrets, and a gitops overlay — all in a dedicated namespace (<owner>--<app>--pr-<N>). The endpoint authorizes the request by probing the workflow's own token for push access on that exact repo, so one app's CI can never touch another app's previews.

The validator uses it too

The preview is what makes the ship gate honest. When a PR is ready, the validator signs into the live preview with a real browser, exercises the core flows, probes security, and posts exactly one verdict comment — ✅ Ship it, ⚠️ Ship with nits, or ❌ Blockers found. It is verifying the same environment you can click around in, not a simulation. See Building with Issues for how verdicts drive merge and rework.

Use it yourself

You don't have to wait for the verdict. Open the preview link, sign in, and try the feature as a user would. If something's off, comment on the PR — while the 🏗️ prefix is on the title, the building agent reads your comments and adjusts. One nice property: features merged dark behind a release flag are automatically switched ON in previews, so you see the new behavior here while prod keeps the flag off until you flip it (see Secrets and Config).

Your own agent can inspect previews too: get_app_status, tail_logs, and query_db all accept env: "pr-<N>" — see Connect Your Agent.


Detail for the curious: each preview build is tagged 0.0.0-pr.<N>.<sha7>. The commit-sha suffix makes every push a distinct chart and image version, which is what guarantees the preview actually rolls on each update — same-tag rebuilds would be invisible to the deploy machinery.