Provision a store (setup wizard)

setup_wizard is the guided way to stand up a real store. It asks for your brand, which modules to enable, tenancy mode, infra profile, and branding (theme, currency, locale), then provisions everything and writes a ready-to-activate .env. It hands the result to seed_client.

Crucially, for a single-box fork it writes TENANCY_SINGLE_TENANT_COMPANY_ID with the actual id of the company it just created — so you never look it up, and the storefront resolves your tenant on the first try.

Tip

Just want a demo catalog to click around? Use seed_client --profile belltex --demo instead — it loads the BellTex sample store. Reach for the wizard when you’re setting up your own store.

Two wizards, two jobs — don't confuse them

This one is the deploy-time tool: it creates the tenant and writes a .env. You run it once, from a terminal, before anyone can sign in.

The first-run setup wizard is different: it runs inside the admin, for a store that already exists, and configures branding, modules, providers and your COD guardrails. That’s the one your merchant sees.

Run it (guided)

1. Start the wizard inside the running API container:

   docker compose exec web python manage.py setup_wizard

2. Answer the prompts — brand identity, modules, tenancy, infra profile, and branding:

   Prompt	What it sets
   Brand name / slug / short name / ops email	the Company record
   Domains	ENABLED_DOMAINS — which modules install (e.g. product, crm)
   Deployment	fork (single-tenant) or saas (host-resolved)
   Infra profile	INFRA_PROFILE — lite or full
   Theme / currency / symbol / locale	storefront branding & commerce config
   Seed demo products?	whether to load a demo catalog too

3. Review the plan and confirm. The wizard prints a summary and asks Apply? — nothing is written until you confirm (or pass --yes).

What it produces

On apply, the wizard:

• writes a composed profile to scripts/client_profiles/<slug>.generated.json,

• runs seed_client with it (Company + TenantConfig + catalog/content), and

• writes a partial env file .env.<slug> (at the repo root) with the deploy-time vars you still need to merge. For a fork that’s:

  APP_NAME="<Brand>"
  ENABLED_DOMAINS=<domains>
  TENANCY_STRATEGY=single_tenant
  TENANCY_ENFORCEMENT=enforce
  TENANCY_SINGLE_TENANT_COMPANY_ID=<the new company's id>   # ← the important one
  INFRA_PROFILE=<lite|full>
  COURIER_ASYNC_DISPATCH=<True|False>
  # …plus FRAUD_/IMAGE_ASYNC_DISPATCH and a DJANGO_TRUSTED_CORS_ORIGINS hint

Activate it

The generated file holds only those deploy-time vars — it is not your whole .env (no DOMAIN, DB_PASSWORD, DJANGO_SECRET_KEY). Merge its lines into your existing .env, then restart.

Docker: the file is written inside the container

Because the wizard runs in the web container, .env.<slug> and the generated profile land on the container’s filesystem, not your host. Read the values out and copy them into your host .env:

docker compose exec web cat .env.<slug>
# Merge those lines into ./.env (at minimum TENANCY_SINGLE_TENANT_COMPANY_ID),
# then reload the env into the containers:
docker compose up -d

Non-interactive (CI / repeatable)

Pass a base profile and skip the prompts and the confirmation:

docker compose exec web python manage.py setup_wizard \
  --profile aurora --non-interactive --yes --demo

--profile is a name in scripts/client_profiles/ or a path. Other flags: --no-demo, --profile-out <path>, --env-out <path>.

How it relates to seed_client

	seed_client	setup_wizard
Input	an existing profile JSON	guided prompts (or a base profile)
Does	Company + TenantConfig + catalog/content	builds a profile, then calls seed_client
Writes .env?	no	yes — .env.<slug> with the tenant pin
Use for	the demo catalog, or re-seeding a known profile	standing up your own store end-to-end

Both are idempotent — re-running updates in place, never duplicates.