Ejecting a template copies Leed’s own version of it into your repository, at a path the build looks for. From that moment your copy renders instead of Leed’s, and it is an ordinary repository file: you edit it, validate it, commit it and push it like anything else. leed site eject is the supported way to do that — it knows where each template’s source lives, where its override belongs, and whether your plan can use it at all.
Not every override works this way. _includes/header-includes.hbs, the shared <head> hook, is not in this registry because there is no Leed default to copy — creating the file is what enables it. Customizing the <head> covers that one.
Seeing what you can customize
Run it with no argument and it prints what this site can eject, what state each one is in, and where each would land:
- Growth workspace
- Free workspace
name status destination description
stub-template Leed default src/_includes/stub-template.hbs Recommendation card markup, cloned once per recommendation in the browser.
unsubscribe Leed default src/_includes/unsubscribe.hbs Email unsubscribe page — full page replacement.
unsubscribed Leed default src/_includes/unsubscribed.hbs Post-unsubscribe confirmation page — full page replacement.
docs-header customized src/_includes/docs-header.hbs Documentation header, inside Leed's positioned wrapper. A working starting example.
docs-footer Leed default src/_includes/docs-footer.hbs Documentation footer. The free tier always keeps Leed's, so the licensing badge stays.
leed site eject <name> name status destination description
unsubscribe Leed default src/_includes/unsubscribe.hbs Email unsubscribe page — full page replacement.
unsubscribed Leed default src/_includes/unsubscribed.hbs Post-unsubscribe confirmation page — full page replacement.
leed site eject <name>status is read from disk, not from a record: customized means a file already exists at the destination, Leed default means it does not and ejecting is safe. The two listings above are the same command on two workspaces — a gated template is not listed at all below its plan, rather than listed and refused. If nothing at all qualifies, the command says so:
No templates are available to customize on your current plan.Taking ownership of one
leed site eject docs-footerThe Leed default is copied to the destination, creating directories as needed, and the CLI confirms:
Wrote src/_includes/docs-footer.hbs — edit and commit it to take ownership.Nothing renders differently yet. The build detects the override by looking for the file, so the swap happens on your next build — and the file is not on your site until you validate, commit and push it like any other change.
A name that is not in the registry is refused with the list of names that are:
Unknown template 'docs-head'. Valid names: stub-template, unsubscribe, unsubscribed, docs-header, docs-footer-f, --force
By default, ejecting over a file that already exists refuses and exits 1:
src/_includes/docs-footer.hbs already exists. Pass --force to overwrite your customization.--force proceeds, and what it does is overwrite your edited file with Leed’s current default.
The five templates
name | What it controls | Destination in your repo | The ejected copy is | Requires |
|---|---|---|---|---|
stub-template | Recommendation card markup | src/_includes/stub-template.hbs | The real partial | Growth and up |
unsubscribe | The email unsubscribe page | src/_includes/unsubscribe.hbs | A shipped scaffold | — |
unsubscribed | The post-unsubscribe confirmation page | src/_includes/unsubscribed.hbs | A shipped scaffold | — |
docs-header | The documentation header, inside Leed’s wrapper | src/_includes/docs-header.hbs | A working example, not a snapshot | Starter and up |
docs-footer | The documentation footer | src/_includes/docs-footer.hbs | Byte-identical to what renders now | Starter and up |
That order is the registry’s order, which is the order the listing prints in.
docs-header
Leed keeps the positioned wrapper, #docs-header-wrapper. Your override replaces everything inside it. The wrapper is not decoration: the docs shell measures it and publishes --height-header, which is the top margin of the page body, so the header’s height has to remain measurable from the outside.
The ejected file is not a copy of what your site currently renders. The live header is filled per layout theme through a partial block — alpha and charlie get the top-search variant, bravo the compact one — so there is no single snapshot to hand you. What you get instead is a complete, working header demonstrating the real API: one menu builder driving both the desktop bar and the mobile drawer from the CMS header menu, the compact document-search partial, the reading-progress bar, and a primary call-to-action. Read customizing the documentation header and footer for the contract before you edit it, and documentation shell partials for what surrounds it.
docs-footer
This one is what renders — the Leed-side file is only the wrapper and the tier check — so ejecting gives you a byte-identical starting point and your first build after ejecting looks exactly like your last build before it.
stub-template
The stub is the markup for one recommendation card. It is cloned once per recommendation in the browser, with data-leed-slot attributes marking where the title, summary, dates, labels, authors and feature image are filled in.
The gate is real rather than cosmetic. Below Growth the recommendations endpoint returns an empty list, so there is nothing to clone the template for — however carefully you author it, it renders nothing. Recommendations describes what the feature does once it is available.
unsubscribe and unsubscribed
Both are ungated, on every plan. They are full-page replacements for the email unsubscribe form and for the confirmation page a reader lands on afterwards, described from the reader’s side in unsubscribes and opt-outs.
These two are the exception to the rule that an ejected file is a real Leed partial. The default unsubscribe markup lives inline in the Leed page that renders it, so there is no partial to copy — the eject source is a scaffold shipped for exactly this purpose. Treat it as a starting point rather than as a description of what your readers currently see.
How the plan check works
The tier is resolved the same way a build resolves it, from your repository’s src/src.11tydata.json — and in CI from the LEED_ENTITLEMENTS build variable and nothing else. It is not a live call to the CMS, so a plan change reaches this command on your next push and rebuild.
There are two distinct outcomes and you will meet both. A template above your plan is not listed at all, as the Free tab above shows. Naming one explicitly gets a different, more useful answer:
'docs-header' requires the starter plan or above; this site is on free.What each tier includes is on feature availability by plan.
Every override slot Leed has, how each is detected at render time and which are gated, is cataloged in overriding Leed templates. eject itself, with every other command and its options, is listed at the CLI command reference.