Skip to main content

Preview deployments

Push a branch, get a running copy of your app on its own URL. A preview is a full deployment with its own database, its own storage, and its own address, so you can click through a change, hand a colleague a link, or let a test suite loose on it, all without touching production.

Previews are the safest place to try something. Because the data is separate, an experiment on a branch cannot read, change, or corrupt anything your live app depends on.

Turning previews on​

Open your application in the console and go to the Source tab.

  1. Pick your production branch, usually main. Pushes to it become production releases.
  2. Set Automatic deploys to Production + preview branches.
  3. Set the preview branch pattern. The default is preview/*, so pushing preview/new-checkout deploys a preview and pushing spike/idea does not. Use * if you want every branch to get one.
  4. Set Max previews, how many run at the same time. The default is three.

From then on, pushing a matching branch deploys it. There is nothing to click: the preview appears in the Deployments tab with its own URL as soon as it is running.

The URL​

Each preview gets its own address, derived from your app name and the branch, so it is stable for as long as the branch exists. Push again and the same URL serves the new commit.

Previews always keep their own AppHaven address, which keeps a work-in-progress branch off the name your customers use.

Who can see a preview​

By default, only the members of your project. Previews follow your app's access mode: under Private and Public, preview branches are reachable only by your project's members, so an unfinished feature is not exposed to the internet while you work on it. If you want anonymous access to previews as well, choose Public, including previews.

Data on a preview​

A preview gets its own empty database and volumes the first time it deploys, and keeps them for as long as the branch lives. That means a migration you run on a branch runs against branch data, which is exactly what makes it a worthwhile rehearsal before the same migration reaches production.

Preview data belongs to the experiment, not to your business, so it sits outside the backup policy: restore points and point-in-time recovery protect your production deployment. Anything you need to keep belongs in production, or in your repository.

When a preview stops​

Previews are automatically stopped 30 days after their last change. A stopped preview frees the CPU and memory it was holding, and its data is kept. Push to the branch again and it starts back up where it left off.

Deleting the branch deletes the preview, along with its database and volumes. Merging a branch and deleting it, the usual end of a piece of work, therefore cleans up after itself.

You can also stop or delete any preview yourself from the Deployments tab at any time.

Promoting a change​

There is no separate promote step, and no rebuild. Merge the branch into your production branch and push. AppHaven recognises that it has already built this exact commit and reuses the image, so production gets the artifact you just tested on the preview rather than a fresh, slightly different one.

Where to go next​

Configuration proposals​

Preview deployment policy can be proposed through the CLI or repository. A developer approves it in Proposals. Approval affects future deployment triggers and does not start previews itself.