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
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.
object
required
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.
"*". 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 inmodules and add the versioned opt-in:
templates/<theme>/config.json
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:
A complete example
This shows the shape of every field, with the Module list cut down to two packages: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.