1 Preview Environments
mitosis edited this page 2026-09-02 08:56:51 +00:00

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

The URL

Each preview lives at:

https://pr-<N>-<app>-<org>.open-platform.sh

<N> is the PR number. The builder posts the live preview link directly on the PR. You rarely need to construct the URL yourself. Open the PR and follow the link.

Lifecycle

The preview tracks the PR exactly.

PR event What happens
Opened / reopened The platform builds the branch and provisions a full environment
Every push The preview rolls to the new code
Closed (merged or not) The platform removes the overlay, the namespace, and the 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). It pushes the image and a Helm chart to the registry. It then POSTs to the platform's in-cluster /ci/preview endpoint.

That one call stands up a complete app instance in a dedicated namespace (<org>--<app>--pr-<N>):

  • its own Postgres database
  • its own Forgejo OAuth app
  • a host, an ingress, and a TLS certificate
  • sealed secrets and a gitops overlay

The endpoint checks the workflow's own token for push access on that exact repo. One app's CI can never touch another app's previews.

The reviewer uses it too

The preview makes the ship gate honest. When a PR is ready, the reviewer signs into the live preview with a real browser. The reviewer exercises the core flows and probes security. It then posts exactly one verdict comment: ✅ Ship it, ⚠️ Ship with nits, ❌ Blockers found, or ❌ Untestable. The reviewer verifies 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 do not have to wait for the verdict. Open the preview link, sign in, and try the feature as a user would. If something is off, comment on the PR. While the 🏗️ prefix is on the title, the builder reads your comments and adjusts.

Features merged dark behind a release flag switch ON automatically in previews. 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.

Why every push rolls

Each preview build carries the tag 0.0.0-pr.<N>.<sha7>. The commit-sha suffix makes every push a distinct chart and image version. A same-tag rebuild would be invisible to the deploy machinery. The sha-suffixed tag is what guarantees the preview rolls on each update.