Documentación

Config Files

ReferenceConfig surfacesFile-by-file map

The template uses a small set of config and content files as the main customization surface.

This page is the practical file-by-file reference.

Reference vs overview

Use this page when you already know you need to change config and want the quickest file-level map. For the conceptual overview, see Config System.

What this reference covers

Brand configuration

Files that define identity, metadata, contact details, and shared asset paths.

Content configuration

JSON files that control marketing content and legal pages, validated by Zod schemas.

i18n labels

Per-locale message files that provide UI labels for auth, dashboard, navbar, and system strings.

Environment defaults

Environment variables that capture assumptions about auth providers, billing modes, and email behavior.

Config reference

src/config/site.ts

Use for product identity and metadata.

Controls:

  • site name
  • site description
  • contact email
  • Resend sender
  • logo paths
  • error image paths

content/landing/*.json

Use for public-facing landing content and structure. One file per locale (en.json, es.json, cn.json), validated by Zod schemas in src/content/schemas.ts and loaded by src/content/loaders.ts.

Controls:

  • hero
  • documentation section
  • testimonials
  • FAQ
  • pricing
  • CTA
  • footer

content/legal/*.json

Use for legal page content per locale.

Controls:

  • terms of service
  • privacy policy

messages/<locale>/*.json

Use for i18n UI labels. Each locale directory contains separate JSON files.

Controls:

  • system.json — global UI strings
  • navbar.json — navigation labels
  • dashboard.json — dashboard section labels and sidebar copy
  • auth.json — authentication flow copy

src/env.js

Use for environment-driven integration defaults validated with Zod.

Controls:

  • auth provider assumptions
  • Stripe price and coupon IDs
  • email API keys (Resend)
How they work together

How these files work together

The config layer is designed so that:

  • site.ts defines who the product is
  • content/landing/*.json defines how the product is presented
  • content/legal/*.json defines legal page content
  • messages/<locale>/*.json provides translated UI labels
  • src/env.js defines which external capabilities the template expects

That separation keeps product decisions centralized instead of scattering them across routes and services.

Editing rule

When a change feels like product configuration rather than feature implementation, check the config and content files first before editing routes or services.