Every Deployment Is a Full Rebuild

Leed rebuilds your entire site on every publish. Correcting one word costs the same as rewriting a hundred pages: the same commit, the same build, the same wait.

That is a design choice rather than an oversight, and it buys something specific. Nothing on your site can be stale relative to anything else on it. The listing page that mentions your post, the sitemap entry, the search index, the feed, the “related articles” block three pages away — all of them are regenerated from the same content at the same moment, so there is no state in which half your site knows about a change and the other half does not.

What a rebuild actually regenerates

Every item below is produced fresh on every single deployment. The right-hand column is the useful part: it is why one changed page is rarely one changed file.

What your visitors get describes the finished article, and feeds, sitemaps and robots.txt covers those three specifically.

Where the time goes

The honest answer surprises most people, because the part they blame is the smallest part.

The site build itself is fast

On a mid-sized site — around a hundred pages — the render takes a handful of seconds, not minutes. Roughly 44% of that time is minifying HTML and JavaScript; the rest is templating, HTML processing, Tailwind and Leed’s own work. Those proportions come from measuring two real repositories rather than from a benchmark, so treat them as the shape of the problem rather than as numbers to plan against.

The practical consequence: making your site smaller is almost never the lever. The render is not what you are waiting for.

The wait is mostly everything around it

What you actually experience is the queue and the plumbing. A deployment waits for a build machine, starts a container, installs the build tooling, renders the site, uploads the finished version, and only then gets activated.

flowchart LR
    A["Queue for a<br/>build machine"] --> B["Start the<br/>container"]
    B --> C["Install the<br/>build tooling"]
    C --> D["Render the<br/>whole site"]
    D --> E["Upload the<br/>new version"]
    E --> F["Activate it<br/>Leed decides when"]

Rendering is one box out of six, and the smallest one. That is why the wall-clock feel is minutes while the build log shows seconds, and it is also why publishing a hundred pages together does not feel meaningfully slower than publishing one.

The ceilings

Two numbers are worth knowing, because both are visible from the Deploy screen.

A build that has not reported back within fifteen minutes is failed automatically — that is a safety net, not a target, and it exists so a build that has silently gone missing does not leave a deployment stuck forever. While anything is in flight, the screen refreshes itself every five seconds, so you never need to reload it.

Expect a couple of minutes end to end. Anything still running after ten is worth expanding and, if it eventually goes red, reading as a failure rather than waiting out the timeout.

What this means in practice

The advice falls straight out of the mechanism:

• Batch related edits. Ticking five items in Pending changes produces one commit and one build; publishing them one at a time produces five. Publishing a selection is the screen for it.
• A scheduled batch is already batched. Pages sharing a publish slot go out as one deployment, which is the cheapest way to release a set of pages at once.
• Watch the order you do things in. Publishing a page and then immediately publishing a settings change is two full rebuilds a minute apart. Publishing the settings first, then the page, costs exactly the same — there is no way to combine them, because pages publish from the editor and settings publish from the Deploy screen.

For developers: iterate locally, not through deployments

The real lever is not to use deployments as your feedback loop at all. Build and serve the site on your own machine, where the loop is seconds.

# The build that ships: minified, and the one `leed site commit` requires
leed site build

# The fast local loop: skips minification, serves on http://localhost:8080
leed site build --debug --serve

A debug build skips minification entirely, which — since minification is most of the render — makes it roughly 40% faster. That difference is exactly what makes an edit-refresh loop bearable.

Local development covers the whole local loop, and leed site build documents every flag the command takes.

One publish, two builds

Publishing to your live site also rebuilds your preview site in parallel, so preview does not quietly fall behind whatever visitors are now seeing. That second build is a real deployment with its own row, badged Published Files into Staging.

It also means the wall-clock cost of a live publish is the cost of one build, not two — they run at the same time, and the live one is not waiting on the preview one.

What the build ships can differ by plan

One difference is worth knowing before you compare two builds. On Starter and above, the build ships the live search client and skips generating a prebuilt search index; below Starter it builds the index and ships it with the site. That is a difference in build output, not in whether you may publish or how fast a deployment runs — publishing, scheduling, retrying and promoting are the same on every plan, Free included.

Live documentation search covers what the difference means for readers; nothing else about a deployment changes with your plan.

Static assets are served straight from the build, which is the other half of why a rebuild matters — static files and caching covers how those files are addressed and served.