Config defaults
How the OpenQuok web app derives default values from Vite env and fallbacks (backend URL, company, landing, navigation).
Connect your agent today
Draft from chat, review in your calendar, and publish only what you approve.
Overview
The web app centralizes its default configuration in:
web/src/lib/config/constants/config.tsThis file exports schema objects like:
- CONFIG_SCHEMA_BACKEND
- CONFIG_SCHEMA_COMPANY
- CONFIG_SCHEMA_MARKETING
- CONFIG_SCHEMA_LANDING_PAGE
Pages and repositories use these defaults when a value is missing from runtime data (for example when backend-provided config hasn’t been set yet).
How defaults are chosen
Some defaults are resolved from Vite env first, then fall back to a safe constant.
Examples:
- API base URL — if VITE_API_BASE_URL is set in .env.development.local, that value is used as the origin for API requests. If it is not set and Vite is in development mode, the default is an empty base so requests use same-origin paths such as
/api/v1/…(required for HTTPS local dev; see Vite (SvelteKit) → HTTPS local development). In non-dev builds when the variable is still unset, the fallback is http://localhost:3000.
Vite env changes require restart/rebuild
When you change VITE_* values, restart the web dev server or rebuild so Vite picks them up.
What each section is for
CONFIG_SCHEMA_BACKEND
- What it controls: where the web app sends API requests.
- Common changes:
- Local HTTPS — leave VITE_API_BASE_URL unset so the dev server proxies
/apito the API (see Vite (SvelteKit)). - Explicit origin — set VITE_API_BASE_URL when you need a fixed API URL (for example production or a custom port).
- Point production web → production API (via your hosting env/secret injection)
- Local HTTPS — leave VITE_API_BASE_URL unset so the dev server proxies
CONFIG_SCHEMA_COMPANY
- What it controls: company/legal identity shown across the site.
- Common changes:
- Company name (
NAME) - Website URL (
URL) - Support email (
SUPPORT_EMAIL) — static default in the schema (and company config when stored) - Legal name / VAT / address (
LEGAL_NAME,VAT_ID,COMPANY_ADDRESS)
- Company name (
- Where it appears (examples): About page and legal pages. Secret admin email sending uses SITE_NAME + SENDER_EMAIL_ADDRESS on the backend; the email manager may still show the schema support email as read-only context.
CONFIG_SCHEMA_LANDING_PAGE
- What it controls: default public home/landing page copy and toggles.
- Common changes:
- Hero title / slogan (
HERO_TITLE,HERO_SLOGAN) - Top banner toggle (
ACTIVE_TOP_BANNER) - Product demo video (
DEMO_SUBTITLE,DEMO_TITLE,DEMO_DESCRIPTION,DEMO_YOUTUBE_VIDEO_ID,DEMO_YOUTUBE_UPLOAD_DATE,DEMO_THUMBNAIL_ALT) - Secondary feature sections (
FEATURE_1_*…FEATURE_7_*— subtitle, title, description per block) - Landing FAQ section (
FAQ_SUBTITLE,FAQ_TITLE,FAQ_DESCRIPTIONon the home page)
- Hero title / slogan (
- Public FAQ section (
CONFIG_SCHEMA_PUBLIC_FAQ—SUBTITLE,TITLE,DESCRIPTION,ITEMSon/and/pricing#faq;ITEMSuses the admin FAQ editor)
Navigation and footer constants
config.ts also exports navigation/footer link constants (for example PUBLIC_NAVBAR_LINKS and PUBLIC_FOOTER_LINKS). These are not env-driven; they’re static defaults used by the public layout. Meta tags, keywords, and social links live under CONFIG_SCHEMA_MARKETING — see SEO & marketing defaults.
Defaults vs stored config
If your backend provides stored company or marketing configuration, pages typically prefer the stored values and fall back to these schema defaults when a field is missing.