Store settings & branding

A whole store’s identity is one data record — the TenantConfig row attached to your Company. Brand, theme, locale, currency, commerce rules, provider selection and feature flags all live there. Standing up a second store is editing this record (plus a theme preset and a seed), never editing code.

Where each setting lives

Three places, with a clear precedence:

Where	What it holds	Wins?
Tenant config — deep-ops console (api.your-domain.com/admin/ → Core → Tenant configs)	Per-store config-as-data: brand, theme, locale/currency, commerce rules, provider selection, feature flags.	Wins where a value is set.
.env — deployment file	Deployment-wide defaults & secrets: DOMAIN, INFRA_PROFILE, ENABLED_DOMAINS, SMTP, commerce fallbacks, and the storefront/admin brand fallbacks.	Fallback — used where the tenant config is blank.
Integrations — deep-ops console → Integrations → App integrations	Provider credentials, encrypted at rest.	N/A — secrets only.

Config-as-data wins

Almost everything a merchant changes day-to-day is a tenant config edit (data) — it takes effect without a restart (the frontends refresh within ~5 minutes, or immediately after docker compose restart storefront admin). The .env values are the safe defaults a store degrades to when a field is left blank. Neither is ever a rebuild.

Store & brand settings (tenant config)

Set in the deep-ops console under Core → Tenant configs. Blank fields fall back as noted.

Brand identity

Setting	Purpose	Default
brand_name	Store name shown across the storefront	blank → falls back to Company.name (then the APP_NAME env fallback)
tagline	Short brand line	blank → Company.slogan
support_email	Customer support email	blank → Company.email
support_phone	Support phone	blank
support_whatsapp	WhatsApp contact	blank
support_hours	e.g. “9 AM – 9 PM, every day”	blank
social_links	JSON map, e.g. {"instagram":"…","facebook":"…","youtube":"…"}	{}

Logo is uploaded on the Company record (Company.logo), with BRAND_LOGO_URL as the env fallback.

Locale & currency

Setting	Purpose	Default
default_locale	Primary locale, e.g. en, bn	en
locales	Offered locales, e.g. ["en","bn"]	[] (→ just the default)
currency	ISO currency code	USD
currency_symbol	Symbol shown in prices	$
timezone	Store timezone (IANA)	UTC

Layout

Setting	Purpose	Default
theme_preset	Which storefront theme preset to load — see Theme presets	default
container_max_width	Storefront content max width (px)	1280
theme_tokens	Runtime colour-token overrides, e.g. {"accent":"#0e7490"}	{}

Brand fallbacks via .env

The storefront and admin containers accept these env fallbacks, used only when the tenant config doesn’t set the value (the tenant config always wins):

Variable	Falls back for	Notes
APP_NAME	brand name	set it to your store’s name
BRAND_LOGO_URL	logo	a public image URL
BRAND_ACCENT	accent colour	must be a valid CSS colour; maps to the storefront’s accent token (and its hover/pressed/soft derivatives)

# .env — the storefront/admin read these at start-up
APP_NAME="Aurora Living"
BRAND_ACCENT=#6D5EF6
BRAND_LOGO_URL=https://cdn.example.com/logo.svg

Runtime vs a themed build — the honest boundary

Colours, logo, name, and preset choice are runtime — a tenant-config edit or an .env change and a restart. A wholly new preset (new fonts, new layout) is a themed build. Everything a merchant changes day-to-day is on the runtime side.

Deployment-level .env (essentials)

The deployment-wide knobs (full .env reference is in .env.example):

Variable	Purpose	Default
DOMAIN	Shop domain; the api./admin. hosts, allowed hosts, CORS & CSRF derive from it	localhost
INFRA_PROFILE	lite or full — see Architecture	lite
ENABLED_DOMAINS	Which domain modules load	all installed
DJANGO_EMAIL_*	SMTP for transactional email	—

More: The .env in the Quickstart · commerce numbers in Delivery zones & fees · providers in Payment providers.

Moving to a new domain

1. Add the three DNS A records for the new domain (@, api, admin); keep the old ones until you’re done. See DNS & TLS.

2. Edit .env: DOMAIN=new-domain.com and docker compose up -d. Caddy fetches new certificates on first request; the frontends pick up the new URLs at boot.

3. Verify each app’s derived config:

   curl -s https://new-domain.com/api/config          # siteUrl + apiBaseUrl
   curl -s https://admin.new-domain.com/api/config
   curl -s https://api.new-domain.com/health/

Checking a running app’s config

curl -s https://your-domain.com/api/config | python3 -m json.tool

Public values only (brand, theme, currency, flags) — secrets never appear here, by construction.