A preview deployment runs a pull request as its own copy of a service, at its own address, so you can try a change before merging it. Hangar creates it when the pull request opens, redeploys it on every push to the pull request and removes it when the pull request is closed or merged.
Preview deployments work for services built from a repository connected through GitHub.
Turn them on
Open the service's Deployments tab, go to the preview settings and switch on Enable preview deployments. From then on, every pull request opened against the service's branch gets a preview.
Hangar comments on the pull request with the state of the preview and its address, and keeps the comment up to date.
Address
Each preview gets a host name of its own under a wildcard domain. By default that is the wildcard of the service's region, so previews work with nothing to configure. You can set your own wildcard domain instead, and choose the port and path the preview is served on, and whether it gets an HTTPS certificate.
Variables
Previews do not use the service's production values. They have their own environment variables, build arguments and build secrets in the preview settings, so a preview can point at a staging database or a sandbox payment key instead of the real ones.
Which pull requests get a preview
- Author permissions. By default, Hangar only deploys a pull request whose author has admin, maintain or write access to the repository. A pull request from anyone else is skipped, and the comment says so. This stops strangers from running code on your account through a fork.
- Labels. If you list labels in the preview settings, only pull requests with one of those labels get a preview. With no labels, every pull request does.
- Limit. A service runs at most 3 previews at a time by default. You can raise or lower the limit; once it is reached, new pull requests are skipped, while existing previews keep updating.