Try Changes on a Staging Site First

Rebuilding a page you are unsure about, on the site people are using, is an uncomfortable way to work. You can now point a second site at the same repository and a different branch, so the work in progress has somewhere to live.

Push to main and your live site rebuilds. Push to staging and only the staging copy does. Turn on password protection and nobody finds it in the meantime.

What it takes

Create a second site, give it the same repository URL, set the branch, then add its deploy key and its webhook to the repository next to the ones you already have. Five minutes, and the staging sites guide walks through each step.

The second webhook catches people out, so it is worth saying why. Every site has its own secret, and a push tells us which site it belongs to by the secret it carries. The two sites can never trigger each other by accident, and either one can be removed without disturbing the other.

What it costs

Nothing. Hosting is free, password protection is free, and a staging site is an ordinary site in every other respect: it takes a custom domain such as staging.example.com, it keeps its own analytics, and its build logs are its own.

One thing to watch

Forms and booking widgets are identified by an id in your markup rather than by the address of the page, so a staging page carrying your live ids writes to your live data. A test booking made that way is a real booking. Give the staging site its own form and its own booking page and read the ids from a per-site environment variable; the guide shows how.

We also fixed the bug underneath all this while we were there. Two sites on one repository used to confuse the webhook, and one of them would quietly stop deploying. That is gone.

Questions to .