---
title: "Published versions and deploy hooks | Briks"
url: https://briks.dev/docs/publish-history
description: "See every version your site has published, restore one, and make deploy hooks: private addresses that publish your site again when another tool calls them."
last_updated: 2026-10-08
---

# Published versions and deploy hooks

Every publish of your site is kept as a numbered version, and the **Versions** section of the project's **Settings** lists them. **Deploy hooks**, in the same Settings, let another tool ask Briks to publish your site again. This page covers both.

7 minute read Checked against the studio on 8 October 2026

## The list of published versions

Where

1. Projects
2. Your project
3. Settings
4. Versions

The section lists the latest 100 versions, newest first. Each row shows:

- **Version** and its number, with a green **Live** tag on the one visitors see now.
- How it came about: **Built**, **Changed**, **Checked and repaired** or **Published again**, and who asked for it.
- The date and time it was published, such as 8 Oct 2026, 14:32.
- A short summary. For a change, it is the words you asked with; for a build or a fresh publish, it is what Briks did.
- Once a version has been live for a week, a line on whether it helped (see below).

| Label | What made the version |
| --- | --- |
| **Built** | A first build, or a new project copied from a template or another project |
| **Changed** | A change you asked for, code you saved in File Explorer, or a picture you swapped from the media library |
| **Checked and repaired** | A site check that fixed something it found |
| **Published again** | A move to production or back to preview, **Apply to the live site**, a new address, a domain going live, or a deploy hook. Its summary says which, such as “Published again with the site's settings.” |

For every job on the project, including ones that published nothing, see [Logs](https://briks.dev/docs/logs).

### Did the change help?

Once a version has been live for 7 days, its row gains a line that compares visits before it with visits since, for the pages the version changed, each as a week's average over up to 14 days either side. It reads, for example, “Since version 12 (Add a prices section), enquiries from /prices went from 3 to 5 a week, on similar visits.” When those pages had fewer than 25 visitors a week, it says there were too few visits to tell. A change an agent made is named as that agent's. The line is worked out from your own [analytics](https://briks.dev/docs/analytics) with no AI and costs nothing. Versions that were only published again, and the first build, get no line. The latest 12 versions are read, and a read is final once 14 days have passed.

### Restore a version

1. Find the version

   Where: Settings, Versions

   Every row except the live one has a **Restore** button, if your role lets you edit the project.

2. Restore it

   Where: Restore version

   Press **Restore**. The dialog says “It goes back on the live site exactly as it was published. The versions after it stay saved, so you can come back.” Press **Restore version** and the number.

3. Watch it publish

   Where: Studio

   Briks takes you to the studio while it publishes. The message reads, for example, “Version 12 is live again, exactly as it was published.” The **Live** tag moves to that row.

A restore runs no AI. Owners, Admins and Editors can restore; Viewers can see the list. It is not possible while an A/B test is running. [Versions, undo and redo](https://briks.dev/docs/versions) covers the same history from inside the studio.

## What a deploy hook is

A deploy hook is a private web address that publishes your site again whenever something calls it. (To deploy is to publish.) You give the address to another tool, such as a scheduling service, and that tool calls it when it wants a fresh publish.

A call publishes the live version again from its own files, with the project's settings as they stand. No AI runs, nothing is charged, and nothing changes that you did not already change. Your site's pages are put together when it is published, not each time someone visits, so a fresh publish picks up:

- the latest published records from the site's database, for any pages built from them;
- settings you have changed since the last publish, such as the logo, the favicon or the search settings;
- anything a page works out at the moment it is put together.

It does not make changes you describe, read data from the tool that calls it, or run the launch check.

When you do not need one

Changes you ask for in the studio publish by themselves. So do edits in the **Database** tab: the site is published again right after an edit, then at most once every five minutes however many edits you make. A deploy hook is for publishes that start outside the studio.

## Make a deploy hook

1. Open Deploy hooks

   Where: Settings, Deploy hooks

   Open your project, click the **Settings** tab, then **Deploy hooks** in the **Developer** group.

2. Add one

   Where: Add a deploy hook

   Press **Add deploy hook**. Name it after what will call it, such as `Nightly scheduler`, and press **Make hook**.

3. Copy the address

   Where: Your deploy hook

   Briks shows the address once. Press **Copy** and paste it straight into the tool that will call it. Briks keeps no readable copy, so you cannot see it again later.

4. Finish

   Where: Your deploy hook

   Press **Done**. The hook joins the list with the date it was made and “never called”.

Hooks start working once the project has been published; until then the section says so. Owners, Admins and Editors can make and delete hooks.

Keep it private

As the dialog warns, anyone with the address can publish your project again. Keep it where only your tools can read it. If it leaks, delete the hook and make a new one.

## Calling a hook

The tool must send a POST request to the address (the kind of web request that asks for something to happen, rather than just reading a page). Most automation and scheduling tools have a setting for this. The dialog shows the shape of a call made from a terminal: `curl -X POST https://app.briks.dev/api/hooks/bdh_…`, with your full address in place of the shortened one.

| When the call arrives | What happens |
| --- | --- |
| The site is ready | A publish starts and shows in the studio like any other. |
| A build or publish is already running | The call is accepted and joined to it, so a burst of calls publishes once. |
| The hook was called six times in the last hour | Refused: “This hook was called six times in the last hour. Try again later.” |
| The project has never been published | Refused: “The project has not been published yet.” |
| An A/B test is running | Refused: “An A/B test is running on this site. End it by keeping one version first.” |
| Neither the person who made the hook nor the one who made the project has a Briks account any more | Refused: “This hook has no owner left. Make a new one in the project's Deploy hooks.” |
| The hook was deleted | The address no longer works. |

Each call updates the “last called” time on the hook's row, so you can see your tool is working.

Use a scheduler outside Briks

The project's own **Scheduled tasks** cannot call a deploy hook, because they refuse addresses on briks.dev. To publish on a timetable, use a scheduling service you already have.

## A worked example

Example A nightly publish for a running club

> Northside Running Club's site lists upcoming races from records in its database. Its organiser asked in the studio whether the races page works anything out from the date when it is published. The answer was yes: it picks the races still to come at that moment. So she made a hook called `Nightly scheduler` and set the scheduling service she already used for club emails to send a POST to it at 03:00 every night.

Each morning the races page starts from that day. The hook's row shows when it was last called, and **Versions** gains one row a night with the summary “Published again with the site's settings.”

Bear in mind that every publish adds a version, so a nightly hook adds about thirty rows a month to **Versions**, and the list shows the latest 100. If you are not sure whether a page depends on the date, ask in the studio first (see [Asking questions](https://briks.dev/docs/asking-questions)); questions are answered without a build.

## Deploy hooks and webhooks

|  | Deploy hook | Webhook |
| --- | --- | --- |
| Direction | Another tool calls Briks | Briks calls another tool |
| What it does | Publishes your site again | Tells the tool that something happened |
| When | Whenever it is called | On site.published, form.received or record.changed |
| Where | **Settings**, **Deploy hooks** | **Settings**, **Webhooks** |

They work well together. A webhook on site.published can tell another tool each time a publish finishes, including one a deploy hook started (see [Webhooks](https://briks.dev/docs/webhooks)).

## Delete a hook

Press **Delete** on the hook's row. The confirmation says “Its address stops working at once.” Press **Delete** again. Tools still calling it get no publish, so remove the address from them too.

## Read next

- [Working on a project **Versions, undo and redo** Every build and change is saved as a version of your site. Undo a change, redo it, or put any earlier version back live exactly as it was, with no credits held.](https://briks.dev/docs/versions)
- [Data and automation **Webhooks** Send a signed message to another tool when your site is published, a form is sent or a record changes. Payloads, signatures, retries and deliveries explained.](https://briks.dev/docs/webhooks)
- [Data and automation **Scheduled tasks** Run a scheduled task on your site at set times: a morning summary, a weekly tidy up. Write a schedule, read each run, fix one that fails, and see plan limits.](https://briks.dev/docs/crons)
- [Data and automation **Logs** Read the build log and the last day of your site's requests, filter by level or status, and track down a failing form, a failing job or a slow page.](https://briks.dev/docs/logs)

Still stuck?

Write to [hello@briks.dev](mailto:hello@briks.dev) with your project's name and what you expected to see. A screenshot helps.