Your content lives in the CMS. Your site’s code — the layouts, the CSS, the static files — lives in a Git repository. Neither of them is a website: a build turns both into one, and until that build runs and its result is activated, nothing you have done is public. Almost every surprise a new team hits in its first month is a consequence of that one sentence, so it is worth ten minutes to see where the pieces sit.
The four parts
The CMS
The CMS at app.leed.ai holds pages, menus, labels, forms, email layouts, assets, contacts and settings. It owns what the site says and who is allowed to say it — roles, overrides and the team list all live here.
Two properties define how it feels to use. Everything autosaves, so there is no Save button and no unsaved-changes state. And nothing in it is public: a draft, an edit to a live page, a renamed label and a changed setting are all private acts until something publishes them. Everything the CMS holds is laid out in How Content Is Organized.
Your site repository
Every workspace has a Git repository holding the site’s code: Handlebars layouts and partials, Tailwind CSS, static files, and JSON data files under _data. It owns how the site looks. Most teams never open it — the starter templates render a complete site on their own — and a developer who does open it clones it with the Leed CLI and works locally.
Two branches matter, and only two: staging builds your preview site, main builds your live site. The repository’s folders, its branches and the tooling the CLI installs into it are in Your Site Repository, and the templates themselves in How Templates Work and How Styling Works.
Your published site
The published site is a static site built from both of the above — your content and your templates, rendered together — served on your own domain. There is a second copy on staging.<your-domain>: same repository, different branch, and it is the one your team looks at before anything reaches readers.
Until you point DNS at Leed, your site answers on a *.leed.workers.dev address instead of your own domain, and the Visit live site and Visit preview site buttons on the Deploy screen always point at whichever is current. What a reader actually receives is in What Your Visitors Get; pointing your domain is Domains and DNS.
The AI layer
There are two halves, and they run in different places. On the CMS side, the Leed Assistant works inside the app for Administrators, and the Operator MCP at https://app.leed.ai/mcp lets your team’s own AI clients read the workspace and draft in it. On the reader side, the Docs MCP and the site AI agent run on your origin, served by your own site — not by Leed — which is why they only exist once your site is published.
The boundary that matters is the same on both sides of the CMS: reads are broad, writes land as drafts and tracked suggestions, and publishing stays a human action. No AI client can put something in front of your readers. All five AI surfaces and who each one is for are in AI in Leed; the reader-facing half is Docs MCP and the Site AI Agent.
How a change travels
flowchart LR YOU["You edit<br/>in the CMS"] -->|"publish a page"| DEP YOU -.->|"change a setting, label,<br/>form or menu"| PEND["Pending changes<br/>waiting on the Deploy screen"] PEND -->|"you publish them"| DEP DEV["A developer edits<br/>the site repository"] -->|"leed site push"| STG["staging branch"] STG -->|"builds automatically"| PREV["Preview site<br/>staging.your-domain"] PREV -.->|"you promote it"| DEP DEP["A deployment<br/>on the main branch"] --> BUILD["Full site build"] BUILD --> ACT["New version uploaded,<br/>then activated"] ACT --> READER["Your reader"]
The dashed edges are the two steps nothing does for you. Everything else runs on its own.
Follow one page through it. You type, and every keystroke autosaves into the draft — still private, still invisible to readers. You publish, and Leed commits your content and creates a deployment: one row, on the main branch, with a reason recorded on it. The deployment runs a build of the entire site from your content and your templates together. When the build succeeds, the new version is uploaded and then activated, at which point the reader’s next request gets the new page. A page publish needs no second action from anybody — you publish, and it goes.
A developer’s change takes a different road to the same place. Edit a template, run leed site build --serve to see it locally, then leed site push. That push lands on staging, builds your preview site, and stops there. To put it in front of readers, someone promotes preview to live from the Deploy screen — which merges staging into main and creates a deployment exactly like a page publish does. Local Development covers the loop, and What Happens After You Push traces the rest of it step by step.
Two branches, two sites
| Preview site | Live site | |
|---|---|---|
| Branch | staging | main |
| Where template changes land | Directly, on leed site push | Only when someone promotes preview to live |
| Who sees it | Your team, via Visit preview site on the Deploy screen | Everyone |
| Form submissions and analytics | Accepted and discarded — nothing is recorded | Recorded as normal |
| Docs MCP and the site agent | Not served | Served |
Two consequences are worth carrying away. First, you can safely fill in your own forms on preview to check them — no contact is created, and no analytics event is stored — but you also cannot use preview to test that a submission arrived. Second, the shipped robots.txt is the same on both sites, and Leed does not add a noindex to preview; if you want your staging copy kept out of search results, that is a change you make in your repository.
Preview Site vs Live Site gives the two-site model its full treatment.
What has to happen before anything is public
Three different kinds of change, three different second steps:
- A page goes out when you publish it. That queues a deployment by itself; there is nothing else to do.
- A setting, label, page type, form, menu or team member does not queue anything. Each change is staged and collects on the Deploy screen under Your edits, where you tick the ones you want and publish them together. Publishing Changes covers that list and what appears on it.
- A template push lands on preview and stays there until someone promotes it.
This is what the amber “must publish” dots scattered across the CMS are telling you: a screen you have edited is holding a staged change that no deployment has carried yet. Publish Reminders and the Must-Publish Model explains where they appear and how to clear them.
Where each part is documented
The CMS side of the model — pages, page types, menus, labels and paths — starts at How Content Is Organized, and the words themselves are defined in Core Concepts. The repository, its branches and the files you may and may not edit are in Your Site Repository, and a developer who wants a terminal rather than a tour should go to Quick Start for Developers. The full pipeline, step by step, is How Publishing Works. And the AI layer, in all five of its forms, is mapped on AI in Leed.