Skip to main content
In development. 86d is being built in the open. Every capability is Experimental until it earns evidence, so check maturity levels before you rely on anything here.
Seven top-level commands: dev, init, status, doctor, module, template, and generate. Each section below covers one. For the shape of a normal working session, see the CLI overview. Several subcommands accept an alias: add also answers to install, update to upgrade, list to ls, activate to use, remove to rm, and components to component-docs.

​
86d dev

Starts the Next.js dev server. It loads .env, .env.local, and .env.development.local in that precedence order, checks that DATABASE_URL is set and reachable, then runs turbo run dev --filter=store.
Flags Example

​
86d init

Sets up a local Store. It:
  • creates .env from the root .env.example if one is missing
  • replaces the BETTER_AUTH_SECRET placeholder with a random 32-byte value
  • installs dependencies with bun install
  • runs code generation
  • offers to run database migrations, when DATABASE_URL is set and reachable
  • offers to seed demo data, on the same condition
Run interactively, it asks before migrating and before seeding, and prompts for the Store Admin email and password. In a non-TTY environment such as CI, database setup is skipped because there is nobody to answer. Flags

​
86d status

Prints a summary: root directory, active Template, which Modules are on and off, environment variable status, dependency state.
Worth running right after 86d init.

​
86d doctor

A deeper diagnostic. Each check reports pass, warn, or fail, and every failure comes with a suggested fix:
  • Node.js version: 23, 24, or 25
  • Bun is installed
  • project root and turbo.json
  • dependencies and lockfile
  • active Template and whether its config.json parses
  • Module integrity: each has package.json and src/index.ts, and every enabled Module exists
  • required environment variables: DATABASE_URL, STORE_ID, BETTER_AUTH_SECRET
  • optional ones: RESEND_API_KEY, NEXT_PUBLIC_STORE_URL, NEXT_PUBLIC_GOOGLE_TAG_MANAGER_ID
  • database connectivity, by opening a TCP connection to the host and port in DATABASE_URL
  • code-generation scripts are present
  • TypeScript configs are present
doctor requires STORE_ID even on a Store you host yourself. That is a CLI limitation, not a Control Plane requirement. Setting it is harmless and worth doing anyway on any deployment you intend to keep. See environment variables.
Reach for doctor when something is wrong and you do not know what.

​
86d module create <name>

Scaffolds a Module at modules/<name>/: entry point, schema, Store and admin endpoints, components, and a starter test.
Then wire it in:
  1. Run 86d module enable <name>, or add "@86d-store/<name>" to your active Template’s config.json by hand.
  2. Run 86d generate.

​
86d module add <specifier>

Installs a Module from the registry, a GitHub repository, or npm. The CLI downloads it to modules/<name>/, fetches its dependencies, runs bun install, and enables it in the active Template. Specifier grammar Examples
Run 86d generate afterward, or the Module is downloaded and doing nothing.

​
86d module update [name]

Compares each installed Module against the registry by version and integrity hash, then lists what has an update. Pass a name to check one.
It reports; it does not apply. Re-run 86d module add <name> for anything you want updated.

​
86d module list

Lists every Module in modules/ with its version and category, and marks which ship Store components or admin endpoints.

​
86d module search [query]

Searches the registry by name, description, or category. A green dot means you already have it locally.

​
86d module info <name>

Shows a Module’s version, category, declared id, Store and admin endpoint counts, the actual endpoint paths, whether it has components on either side, and whether it ships tests. For a Module in the registry but not installed, you get the registry summary and how to install it.

​
86d module enable <name>

Enables a Module in your active Template’s config.json. If that file uses "modules": "*", this command does nothing, and the wildcard admits no Experimental Modules either. Convert modules to an explicit list and add the versioned advanced opt-in.

​
86d module disable <name>

Disables a Module in your active Template’s config.json. If that file uses "modules": "*", this converts it to an explicit list with the named Module left out.

​
86d template create <name>

Copies brisa to templates/<name>/ and updates theme and name in the new config.json. This is the starting point for your own design.

​
86d template add <specifier>

Adds a Template from GitHub or npm. Specifier grammar Examples
The command fails if the downloaded Template has no config.json, and the Template has to ship an explicit modules array. The CLI writes no placeholder for you. Copy the shape of templates/brisa/config.json.

​
86d template remove <name>

Deletes a Template from templates/. The CLI refuses to remove brisa or whichever Template is currently active. Switch first with 86d template activate.

​
86d template list

Lists your Templates, with the active one marked.

​
86d template activate <name>

Switches which Template your Store uses, by rewriting the template/* path alias in apps/store/tsconfig.json.

​
86d generate

Runs every generator: the registry manifest, Module imports and the API router, and component documentation. Run it after any config.json change.
Sub-commands