⚙️ Configuration

There are three configuration layers.

starter.config.json is committed. Never put secrets in it.

There is no root .env. Each app has its own file.

Don’t edit the generated config files. Change the root file and let GoShipped sync them.

Start with the product file

Before you redesign anything, replace the shipped identity in starter.config.json:

• app.name / app.description / app.defaultLocale
• branding.logo, branding.logoDark, branding.favicon, branding.colors
• support.email
• features.*

The shipped values are working examples. They are not your product.

Keep the app name at 24 characters or fewer (32 is the hard maximum). Put logo files in apps/web/public/ and point the config at them, for example "/my-logo.svg".

While pnpm dev is running, edits to starter.config.json sync automatically. You usually do not restart the server.

pnpm config:check   # validate only
pnpm config:sync    # validate + copy into both apps

pnpm dev and pnpm build already run sync. Do not edit the generated copies:

• apps/web/src/config/generated/starter.config.json
• apps/web/src/config/generated/starter-theme.css
• apps/api/app/generated/starter_config.json

Those exist so Vercel can deploy apps/web and apps/api as separate projects.

Marketing copy is separate

Product name and colors stay in starter.config.json so the app and the website stay aligned.

Everything the public site says lives in apps/web/src/config/marketing.ts:

• hero, features, FAQ, footer
• sections.* — set a section to false to hide it
• company legal name, address, jurisdiction

Legal pages are starter templates, not legal advice. Review them before production.

Secrets stay in env files

pnpm run setup copies the examples when the local files are missing. It never overwrites existing files.

Typical env concerns: Supabase, OpenAI, Anthropic, Stripe, Resend, Sentry, the database URL.

Feature flags

Flags in starter.config.json turn capabilities on or off for the whole product — UI, API, and runtime. They are not “hide this button”.

{
  "features": {
    "signup": true,
    "onboarding": true,
    "billing": true,
    "files": true,
    "memory": true,
    "deepResearch": true,
    "mcp": false,
    "tools": {
      "webResearch": true,
      "urlReader": true,
      "weather": true,
      "stocks": true,
      "shopping": true,
      "domains": true
    }
  }
}

Plans still decide which enabled features each user can access. A flag set to false cannot be turned back on by a plan.

Product capability → Plan entitlement → Usage quota → Request

Direct API calls to a disabled capability return 404 with feature_disabled.

What each flag controls

Helpers, if you need them in code:

• Frontend: apps/web/src/config/features.ts → isFeatureEnabled("billing")
• Backend: apps/api/app/features.py → is_feature_enabled / require_feature

There is no remote flag service and no flags table in the database.

Only pay for what you enable

GoShipped should only require credentials for functionality you actually turn on.

Doctor follows that rule. Disabled product features are skipped and do not require their exclusive secrets.

Chat still needs at least one AI provider: OPENAI_API_KEY and/or ANTHROPIC_API_KEY.

Without Stripe, every user gets DEFAULT_PLAN_WHEN_BILLING_DISABLED (default pro). Checkout and the customer portal stay unavailable until you add keys.

Setup and doctor

Use these instead of editing env files from memory:

pnpm run setup    # guided, interactive, writes missing files
pnpm run doctor   # read-only report, safe in CI

Setup asks for missing values. Skipped optional services are later tasks, not red errors — except Stripe while features.billing is still true.

Doctor groups include Configuration, Environment, Supabase, AI, Billing, Files, Memory, Deep Research, MCP, Email, Observability, and Tools. When something is missing, it tells you the file and where to get the value.

What to do next

You know where identity, copy, flags, and secrets live. That is enough to start building.