Configuration

Most configuration lives in @repo/config (packages/config/src/index.ts) - one typed config constant the backend and the frontend both import, so a value changed once propagates everywhere. It is pure static data: no process.env, so a packaged desktop app and a sandboxed renderer can import the same module.

Where configuration lives

How flags gate features

Toggleable features are a discriminated union - { enabled: false } | { enabled: true; ... } - so reading config.X.enabled narrows the type and exposes provider fields only when on.

import { config } from "@repo/config";

if (config.payment.enabled) {
  // config.payment.provider is now available ("stripe" | "polar")
}

Feature flag reference

Shapes that break the { enabled } pattern:

• config.apiDocs and config.waitlist are bare booleans - read them directly, with no .enabled.
• config.performanceMonitor.enabled toggles the Hono request logger. Fullstack projects generate it false (Next.js logs requests natively, so the mounted API would double-log); separate-backend projects generate it true - see api.
• config.observability has no enabled flag and no provider selector: a provider runs when its own credential is non-empty, and both may run at once - see error reporting.
• config.analytics, config.support, config.affiliate are presence-gated - each provider activates when you add its sub-config - see integrations.
• config.email has no off switch - you only pick its provider - see email.

The desktop app's AI orchestration gates on config.desktop.agents.enabled, which a desktop project derives from your AI option rather than a separate switch. Every desktop project ships the agent runtime the app forks, so flipping the flag on turns those screens back on with no regeneration. See desktop AI.

Identity, branding, and SEO

Rebranding walks these fields one by one in customization.

CORS origins

config.origins lists the origins allowed to call the backend, as both the Hono CORS allowlist and Better Auth trustedOrigins.

• It is static data, so it holds your development origins and any origin you want committed.
• The backend unions it with TRUSTED_ORIGINS (comma-separated env), which is where a per-deployment production URL belongs.
• baseUrl is never auto-trusted. Every origin you serve from must appear in one of the two - see environment variables.

Routes - never hardcode paths

config.routes.* centralizes shared in-app paths (home, auth, loginRedirect, dashboard, pricing, onboarding, settings, chat, automations, settingsModels, settingsIntegrations, settingsRunners, settingsMcp, settingsBilling, notifications, admin, adminOrganizations, adminBillingLogs) so a path change is one edit.

import { redirect } from "next/navigation";
import { config } from "@repo/config";

redirect(config.routes.loginRedirect); // "/dashboard" - survives a path change

Use config.routes.* for any redirect or shared link. Framework-idiomatic route construction (locale prefixing, navigation helpers) lives in data fetching.

AI product - config.ai

config.ai sets who pays for inference and which models are pickable. The AI page covers what it ships.

Barrel exports

@repo/config also re-exports named values that are NOT keys on config - import them directly.