Skip to main content
Reviewers should be able to open a link on a pull request and see the change running, instead of reading a diff and imagining it. Ankra deploys every pull request on a connected application to your organisation’s staging cluster, keeps one status comment on the pull request up to date, and tears the preview down when the pull request closes. A preview deploys an image that was already built for the pull request. Which image that is depends on how the application is built - see Where the preview image comes from before you rely on previews.

​
What you get

Once the pull request’s image exists, a comment like this appears and keeps itself up to date:

​
🚀 Ankra Preview

⏳ Expires Aug 9, 22:26 UTC · 🔁 Redeploys on every push
The preview runs in its own isolated namespace on the staging cluster, PodSecurity-hardened and quota-bounded, exactly like a manually launched preview demo. When the Ankra GitHub App has the optional Deployments permission, the pull request also gets a GitHub deployment entry, so the preview shows up in the pull request’s environments box.

​
Prerequisites

1

Connect the repository as an application

The repository must be a connected application (GitHub only for now).
2

Make sure pull requests produce an image

An application built with Ankra Pipelines already does: every pull request run builds the head commit. An application built with the generated GitHub Actions workflow does not, because that workflow pushes nothing for a pull request. See Where the preview image comes from.
3

Turn PR previews on for the installation

An admin switches PR previews on under AI → Settings → Connections → Source control & AI review, on the GitHub installation’s All repositories row or on a rule for that repository. It is off on a new installation, and nothing is deployed until it is on. See AI code review.
4

Configure a staging cluster

An admin sets the organisation’s staging cluster under AI → Settings → Workspaces. Without it, pull requests deploy nothing however the switch is set.
5

Optional: bring a demo base domain for HTTPS

By default previews are served under the staging cluster’s own Ankra DNS zone (*.ankra.cc, or the Ankra domain your organisation selected) over plain HTTP. For HTTPS (or your own hostnames), configure a demo base domain with an ingress class and TLS secret in the same settings screen.

​
Where the preview image comes from

Ankra looks for the preview image in one of two ways, depending on what builds the application. The application’s setup pull request decides that: a new application builds with Ankra Pipelines by default. Ship Your App compares the builders.

​
Applications built with Ankra Pipelines

The preview deploys the image the pipeline’s build step pushed for the pull request’s head commit, by digest. Nothing else is needed: the pull request run that the push already starts is what produces it. Ankra never deploys a tag that could still point at an older commit. While that run is still going, the preview waits and the comment says Building. When the run concludes, Ankra deploys straight away. If the run fails before it produces an image, the preview reports Failed with the reason, for example Pipeline run #53 failed to build 524ba32: .... The next push, or a later successful run for the same commit, deploys it. The pipeline needs its CI cluster and an approved definition before it runs at all - see Before your first run.

​
Applications built by GitHub Actions

The preview deploys an image from the application’s registry repository tagged with, in this order of preference:
  1. sha-<7> - the first seven characters of the pull request’s head commit,
  2. pr-<number> - the pull request number,
  3. the branch name, with every character other than letters, digits, ., _ and - replaced by -.
The generated build-and-publish.yml workflow builds and scans the image on a pull request but never pushes it, so it produces none of these tags for a pull request. An application on the generated workflow therefore reports Build unavailable on every pull request. Previews work in this lane only when a workflow of your own pushes one of the tags above for pull requests, or after the application moves to Ankra Pipelines.
Ankra prefers the head’s own sha-<7> tag because a pr-<number> or branch tag can still hold an earlier push’s image.

​
The status comment

One marker-tagged comment per pull request, updated in place - never a stream of new comments. Lifecycle:
  • On open: the preview deploys as soon as the pull request’s image exists.
  • On every push: the preview redeploys with the new head; the comment’s Commit and Updated cells refresh.
  • On close or merge: the namespace is torn down immediately and the comment flips to ⚪ Stopped.
  • On expiry: previews are time-limited (the organisation’s demo lifetime, 24 hours by default) and reaped automatically; pushing again deploys a fresh one.

​
Configuration and data

Automatic previews inherit the application’s demo environment defaults - env vars, secret slots, and the optional throwaway Postgres - configured as the environment template under the application’s Previews section (Preview settings). See environment variables and a throwaway database. If your app needs configuration to boot, set the defaults once and every pull request preview gets them.

​
Troubleshooting

  • Ship Your App - the routes from a repository to a running, redeploying application, and which builder feeds previews
  • Branch demos - the manual launch dialog, its environment variables, throwaway database, and teardown timer
  • Preview demos - launch a demo manually from the portal, CLI, or the deploy_pr_demo MCP tool
  • The preview URL - how the public hostname is resolved
  • Ankra Pipelines - the in-cluster CI whose pull request runs build preview images