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.
Every Template carries a config.json. It sets your Store’s branding, which Modules are on, the options those Modules receive, and the color tokens. Commerce data is not in here: prices, stock, and Orders live in the Store Runtime database, so nothing you type in this file can change what a Shopper is charged. Run 86d generate after every edit.

Where it lives

The starter is at templates/brisa/config.json. Your own Template uses the same filename under its own directory.

Top-level fields

string
required
The Template this config belongs to. Must match the directory name under templates/. The starter uses "brisa".
string
required
Your Store’s display name. It shows in the Storefront navigation, the Store Admin header, and email templates.
string
required
Root-relative path to your favicon, for example "/assets/favicon.svg". SVG works.
object
required
Your square mark with no wordmark, used where space is tight such as a mobile menu. Supply light and dark versions.
Your full logo with wordmark, shown in the navbar and footer. Supply light and dark versions.
string | string[]
Which Modules are on.
  • An explicit array of package names enables exactly those Modules.
  • "*" discovers the catalog but admits no Experimental Modules.
Leaving the field out behaves like "*". Since every first-party Module is currently Experimental, that means nothing loads.
object
Versioned consent for advanced behavior. The resolver recognizes version: 1 with allowExperimentalModules: true.
object
Per-Module settings, keyed by package name. Each Module defines its own options, listed on its reference page.
object
required
OKLCH color tokens, applied as CSS custom properties for light and dark mode. Every supported key is listed under Color tokens.

Turning on an Experimental Module

Every first-party registry entry is Experimental right now. To load one, name it in modules and add the versioned opt-in:
templates/<theme>/config.json
The resolver fails closed when the opt-in is missing, carries the wrong version, or sets the flag to false. "modules": "*" and an omitted modules field discover the catalog, and no amount of advanced flagging makes either form admit Experimental code. Deprecated entries cannot be newly enabled at all.

Color tokens

Colors are OKLCH values. OKLCH is perceptually uniform, so the same lightness change looks like the same change across every hue. Each token becomes a CSS custom property on :root, such as --background or --primary. Define variables.light and variables.dark separately. These are the tokens:
oklch.com lets you pick colors visually and copy the values straight into this file.

A complete example

This shows the shape of every field, with the Module list cut down to two packages:
The starter names all 101 first-party packages pinned in registry.lock.json and opts into their Experimental maturity. Cut that list down to what you actually sell with before this Store leaves your machine. Every Module you leave in is code running in your Store.
templates/<theme>/config.json

Applying a change

Regenerate the Module imports and API router:
bun run dev picks up the result without a restart.
On a Managed Deployment, the complete 86D_STORE_ID, 86D_API_URL, and 86D_WORKLOAD_CREDENTIAL trio wins: configuration is fetched from the Control Plane with a short-lived scoped token, and a failed exchange or fetch stops the boot rather than falling back to this file. Setting STORE_ID on a Store you host yourself does not replace your local config.json.