Preview Deployment

When a team is working on a website or an app, there is one version that all visitors see on the internet. Changes to it would be risky if tried out directly there. That is why, with a preview deployment, a second, fully functional version of the website is started on a server. It contains exactly one planned change and is reachable via its own, usually cryptic, internet address. Anyone who knows this address can click through it and test it just like the real site. Once the change has been reviewed and accepted, the preview version is usually deleted again.

Finding bugs before customers do

The biggest benefit is mundane but crucial: you see the change instead of having to imagine it. In the past, developers sent each other descriptions and screenshots. Whether a payment process actually works or a menu falls apart on a phone only becomes clear when you actually try it. A preview deployment turns this kind of trying-out into the normal case, not the exception.

It also matters who can work with it. You don’t need any programming knowledge for a preview, just a link. So designers, editors, product managers, or a legal department can check it themselves. For companies with high demands on accuracy, for instance in the financial sector, this is a real advantage. An incorrect interest rate on a product page is more likely to be noticed if someone from the relevant department sees it in the browser.

One side effect is speed. Because checking requires little effort, a team dares to make many small changes instead of a few large ones. Small changes are easier to understand and easier to revert if something goes wrong.

From proposed change to its own address

The process begins in version control. This is a program that records every change to the program code along with date and author, usually the software Git. Changes are made there in a separate branch, a so-called branch. If a developer submits this branch for review, a proposed change is created, called a pull request.

This proposal automatically triggers the next steps. A service fetches the code, builds the finished website from it, and starts it on its own server. In the end, a link is attached to the proposed change, often in the form pr-482.project.example.com. The whole process typically takes one to five minutes. Providers such as Vercel, Netlify, or GitLab have this feature built in.

However, a preview is never entirely identical to the real site. It often accesses a test database with made-up data, so that no one alters real customer data. Payment services also run in test mode. So one must know what the preview does not cover: real data volumes, real traffic numbers, real search engines. Anyone who confuses this considers a page tested that is only half so.

Where preview links show up

Preview deployments are most commonly encountered in tools for software teams, such as GitHub or GitLab. There, a comment with the preview link appears under every proposed change. In companies, it is common practice for a change to only be approved once at least one person has opened the preview.

The principle also exists outside of programming. Content management systems show an article in its finished layout before it is published. In no-code website builder tools, the button is often simply called Preview. The idea is the same: look first, then publish.

In news about technology companies, preview deployments mostly come up in connection with developer platforms. They are a selling point for hosting providers and a cost factor, since every preview consumes computing time. And they are occasionally a security topic: preview addresses are rarely secret, but often not protected by a password. On several occasions, unfinished products or internal data have become publicly visible through such links.