How Publishing Works

You can rewrite every page in your workspace, rename your menus, add a form and change your site title, and your visitors will see none of it. Editing in the CMS and publishing to the web are two separate acts. The only thing that changes what a visitor is served is a deployment: a fresh build of your entire site that Leed then switches on.

The screen that does this is Deploy in the left rail, at /deployments. It opens with the eyebrow Publishing, the heading Publish your site, and one line underneath that is the whole idea in a sentence: “Changes you make across the CMS — stay private until you publish them.”

Deployment, revision and preview all have precise meanings in Leed, and reading this page with the everyday senses of those words will mislead you — Core Concepts defines them once.

The three things on the Deploy screen

The top of the screen is a single card, headed How publishing works / Nothing goes public until you publish it, with a summary of your web presence: a preview site your team can review, and the live site your visitors see.

Inside it are three stage cards. Preview site and Pending changes sit side by side; Live site runs full width beneath them.

Two of the three have a page of their own, because each hides more than one card can say. The preview site is a genuinely separate website with its own address and its own deliberate limitations — preview and live are two separate sites. And the middle card’s list is far more specific than “your unsaved work” — the Pending changes list is more specific than it looks.

The Live site card’s scheduled list belongs to scheduling and automatic publishing.

Four ways a deployment starts

“Publish” is not one action. Four different things you can do in the CMS start a deployment — and two more happen on the developer’s side of the workspace. None of the six lands in the same place as all the others.

The last two are the developer’s half of the story. A CLI push is traced step by step in what happens after you push; saving a layout file commits and builds on the spot, with no waiting list, as the Layouts workspace describes.

What runs after you click

Five things happen, in order, and only the last one is visible to a visitor.

1. A deployment row is created. It appears immediately in the history below, badged with why it happened, with no commit hash yet.
2. A git commit lands on the target branch of your site repository — main for the live site, staging for preview. Everything you ticked for the same site goes into one commit.
3. Cloudflare builds your whole site. Not the page you changed — every page, plus the search index, the feeds, the sitemap and the CSS.
4. The build uploads a version of your site worker. A version is a complete, ready-to-serve copy of your site that is not serving anything yet.
5. Leed activates that version at 100% of traffic. This is the moment the change becomes real.

Steps 4 and 5 are separate acts by different parties, and that is the single most useful fact on this page. The build finishes and hands Leed a version; Leed decides when to switch to it. That separation is what lets a scheduled post be built minutes early and still go live exactly on the minute you chose.

sequenceDiagram
    autonumber
    actor You
    participant CMS as Leed CMS
    participant Repo as Site repository
    participant CF as Cloudflare Builds
    participant Site as Your site worker

    You->>CMS: Publish
    CMS->>CMS: Create deployment row (Queued)
    CMS->>Repo: Commit the change to main or staging
    CMS->>CF: Trigger a build of that commit
    CF->>CF: Render every page, index, feed and sitemap
    CF->>Site: wrangler versions upload (a version, not yet serving)
    CF-->>CMS: Build finished + version id
    Note over CMS: Scheduled publishes wait here<br/>until the exact minute
    CMS->>Site: Activate this version at 100% of traffic
    Site-->>You: Row turns Active — visitors see the new build

Why your site never goes down mid-build

The version that is currently serving keeps serving throughout. A build that takes two minutes does not make your site slow, unavailable or half-updated for those two minutes, because nothing is swapped until the new version is complete and Leed activates it.

The corollary is the useful one: a failed build changes nothing a visitor sees. Your old site stays up, exactly as it was. A red row on the Deploy screen is a problem to fix, not an outage. If one appears, read it here first.

How long it takes

Expect a couple of minutes from click to live.

Almost none of that is rendering. A mid-sized site renders in seconds; the wall-clock time goes to queuing for a build machine, starting it, installing the build tooling, uploading the finished site, and activating it. That is also why publishing one typo fix costs about the same as publishing a hundred pages — every deployment is a complete rebuild. Where that time actually goes has the breakdown, and the local-iteration lever for developers who do not want to wait on a deployment to see a change.

Publishing a page — whether you set it to go out now or next Tuesday — is picked up by a job that runs once a minute, so an immediate publish can sit for up to a minute before its row appears. That is the same machinery behind scheduled publishing, and it is why the two look identical in the history.

Reading the history

Below the pipeline card, deployments are listed in two columns — Preview site and Live site — newest first.

Exactly one row per column is Active: the build currently being served on that site. Everything above it is newer but not yet serving; everything below it is history. Each row carries blue badges saying why it happened, a status badge saying where it is, who started it and when. Reading a deployment row covers every badge and what expanding a row shows you.

Who can do what

Three privileges govern this screen. Roles are cumulative: a role is a minimum access level, so anyone at Content Publisher or above can publish.

Whether you see this screen at all, and whether its buttons are live, comes from your role and, for promotion only, the Developer override.

Publishing is free on every plan

Leed gates a handful of features by plan tier. None of them is here. Deployments, unlimited publishing, scheduled publishing, promotion, retries and a custom domain are available on every plan including Free, and there is no monthly deployment allowance to run out of. The one thing on this screen that changes with your plan is which search client your build ships, which is a difference in build output rather than in what you may publish — Feature Availability by Plan is the full list of what is actually gated.

Until your own domain is connected, the Visit preview site and Visit live site buttons point at a temporary Leed-provided address. Your site is genuinely live there, certificate and all — it just is not your address yet. Connecting a domain is the fix.