Deploying

For a statically built site, publishing content is only half of getting it live: something has to rebuild the site.

Telling the CMS how to rebuild

A project declares a deploy target, set in the console under the project's settings:

Target	Use it when
none	Your site reads the API at request time and never needs rebuilding.
pages_hook	Cloudflare Pages. Paste the deploy hook URL.
github_workflow	GitHub Actions. Give the repo, workflow file and ref.

Publishing a release then triggers it.

GitHub Actions

Your workflow needs a workflow_dispatch trigger:

on:
  workflow_dispatch:
    inputs:
      cms_env:
        description: Which CMS environment to build against
        default: production

The token the CMS uses needs actions: write on the repository.

Confirming it worked

A deploy hook returning 200 means your request was accepted, not that the site is serving new content. The CMS therefore checks, and keeps checking on a schedule until it knows.

For each published route it fetches the live URL and looks for two things: markup rendered from CMS content, and this document's own title or description. Both are needed — a coded page can carry the same description as the document replacing it.

A release stays rebuild not confirmed until that passes, and if it fails you get the route and the reason:

Reason	Fix
Not rendered from the CMS	The build that renders this route has not shipped, or a coded page still takes precedence. Republishing will not help.
Older content	A build ran before the release published. Retry the rebuild.
No page returned	Read the build log.

Making your build depend on content

Two checks worth adding, both of which stop a broken deploy rather than reporting one:

Refuse to build when a cut-over route has no document. See The registry manifest.

Refuse to build when the content API is down. A build that generates pages from a failed fetch produces a site with pages missing, and it does it quietly.