The leed CLI is how you work on your Leed website from your own machine: it checks out your site’s files, builds and serves them locally as you edit, and publishes your changes to your preview site. This page gets you from nothing to a first change on preview. Each step links to the page that covers it in full.
Working in Claude Code? The Leed plugin for Claude installs and drives the CLI for you: see Get Started with the Leed Plugin for Claude.
What you need
- macOS, Linux or WSL. The installer is a bash script; on Windows, run it inside WSL.
- git 2.31 or later. The installer stops, with how to install or upgrade it, if git is missing or older.
- Bun 1.1.0 or later. The CLI runs on Bun. If Bun is missing or too old, the installer asks before installing or updating it for you.
- Node.js 22 or later, which the CLI’s package requires.
- Developer access to your company in Leed. An administrator grants it with the Developer checkbox on Settings → Team Members (see Billing and Developer Access). Without it, setup signs you in and then stops with
permission_deniedwhen it fetches your site.
No Leed account yet? You can still build a whole site locally: see Sandbox Sites.
1. Install the CLI
Run the one-line installer in a terminal:
curl -fsSL https://app.leed.ai/install | bashIt checks git and Bun, installs the CLI from the public npm package @leed-ai/cli, sets up shell completion, and then hands over to leed setup (step 2). The same command is also in the CMS: open the profile menu at the bottom of the left rail and choose Developer Setup.
The CLI is an ordinary public package, so you can also install it yourself:
npm i -g @leed-ai/cli
# or
bun i -g @leed-ai/cliA manual install does not sign you in or set up completion, because the package runs no install scripts: follow it with leed completion install and step 2. However you install it, leed runs on Bun, and its automatic updates install with Bun.
Every installer step, version pinning and automatic updates are covered in Installing the Leed CLI.
2. Run leed setup
The installer runs this for you at the end. To run it yourself, or again later:
leed setup --env productionIt works on exactly the environment you name, and never guesses one:
- Signs you in. It opens your browser (or prints the sign-in URL) with a code to approve, and you choose your company on the approval page. If this machine already holds a login, it asks which one to use, or whether to sign in again; there is no default.
- Sets up your site. It asks which folder to keep your sites in,
~/leedby default, and checks out your site there as~/leed/<your-domain-slug>/raw-content, recording it in~/.config/leed/sites.json. A site already set up is kept. - Installs Font Awesome Free and shell completion, and at a terminal offers, once each, a VS Code workspace and the Leed plugin for Claude Code.
It is safe to run again at any time: every step checks before it acts. leed setup --env production --check reports what is left to do and changes nothing. Work for several companies? Run leed setup --env production --new-login once for each. How sign-in works and where the login is kept is in CLI Authentication.
3. Build and preview
cd ~/leed/<your-domain-slug>/raw-content
leed site build --serveThe first build renders your whole site, then serves it at http://localhost:8080 and rebuilds as you edit templates, partials and styles. --port picks another port; one already in use is refused before the build starts. The full loop is in Local Development, and every flag in leed site build.
leed site list shows every site set up on this machine and where it is. Every leed site command works from the checkout or any folder inside it; from anywhere else, name the site with --site.
4. Push your first change
Change something you can see, then publish it in four commands, always in this order:
leed site validate
leed site build
leed site commit -m "My first change"
leed site pushflowchart LR Edit["Edit files"] --> Validate["leed site validate"] Validate --> Build["leed site build<br/>(a plain build)"] Build --> Commit["leed site commit -m"] Commit --> Push["leed site push"] Push --> Preview["Your preview site"] Preview -.->|"Promote on the Deploy screen"| Live["Your live site"]
leed site commit and leed site push take the place of git commit and git push, and a push lands on your preview site, never your live one: someone promotes it from the Deploy screen in the CMS. The rules behind each step are in Validate, Commit and Push.
Where to go next
- Quick Start for Developers: the same path in more depth, including the
--debugtrap that blocks commits. - Installing the Leed CLI: the installer, updates and shell completion.
- CLI Authentication: device sign-in, sessions and several companies.
- Local Development: the build-and-serve loop.
- Validate, Commit and Push: publishing to preview.
- CLI Command Reference: every command and flag.
- Machine-Readable Output (
--json): scripting the CLI. - CLI Troubleshooting and Exit Codes: when a command fails.