> ## Documentation Index > Fetch the complete documentation index at: https://docs.genesiscomputing.com/llms.txt > Use this file to discover all available pages before exploring further. # Config Profiles > Preview, validate, import, export, activate, and restore reusable Genesis configuration profiles. ## Overview **Config Profiles** provides a controlled way to package and apply Genesis configuration. Use it to compare the active environment against a saved profile, dry-run changes, restore drift, import new configuration files, and export current state. Actual Genesis Configuration Profiles page showing premade profiles and import options. ## Status area At the top of the page, Genesis summarizes the active profile, last load time, required-secret status, and drift from the active profile. Quick actions include **Show Changes**, **Show Sources**, **Refresh**, **Save as Profile**, and **Restore Profile**. ## Config sources **Show Sources** opens a modal that lists schema fields with their effective value and which layer in the config priority chain is winning. Non-secret fields report `env_override`, `database`, `db_env_var`, `default_env_var`, or `default_plain`; secret fields report `env_override`, `custom_secret_ref`, or `default_secret_ref`. Filter by section or search by path. Genesis loads this view only when you open the modal. Resolving every field's source is an expensive server operation and is not prefetched on page load. Advanced Settings also shows a per-field source badge on each row; clicking it loads a single path through the same API. ## Work with templates and profiles The main table supports **All**, **Premade**, and **Custom** tabs. From each row, admins can preview the profile, run a dry run, apply it, or delete custom profiles. ## Import and export The import/export section supports YAML and JSON files, validation feedback, save-as-custom-profile behavior, immediate activation, and export of the current configuration. Full profile activation uses `POST /api/config/setup/apply`, which replaces **only the top-level sections present in the file**. Section replaces are **atomic** — if activation fails partway through, touched sections roll back to their prior values. Sections omitted from the file are left unchanged in the database, so a minimal profile (for example just `llm` and `providers`) does not wipe branding, auth, rate limits, or other settings configured elsewhere. Within each touched section, fields absent from the file are cleared and resolve to schema defaults at read time. For SQLite-backed configuration, Genesis holds the shared metadata connection for the full apply, so concurrent table setup cannot interrupt the transaction. When the file includes a top-level `connection` section, Genesis writes each connection as an individual row and **merges** with existing saved connections: connections named in the file override or add, and connections not mentioned survive. Omit the `connection` section entirely to leave all existing connection rows untouched. For targeted YAML/JSON patches that should touch only the paths you send — for example updating `llm.pricing` without touching other fields — use `POST /api/config/setup/apply-partial` instead; it merges onto the current database state and leaves every other field unchanged. Partial apply rejects `connection` payloads; use full apply with a `connection` section (merge semantics above) or manage connections through `/api/connections`. Dict-valued fields such as `llm.pricing` are preserved as a single unit during partial apply and can be read back as one mapping via `get()` or `get_section()`. ## Startup loading On every server restart, Genesis evaluates the configured profile **before** deciding whether the database still needs schema auto-population. This lets mounted or file-backed profiles replace default or `NULL` scaffold rows even when every schema field is already present in `APP_CONFIG`. **Source priority** (first match wins): 1. `GENESIS_CONFIG_FILE` environment variable 2. `GENESIS_CONFIG_TEMPLATE` environment variable 3. Saved active profile path in the database (`_profile.path`) **Apply behavior:** | Condition | Behavior | | - | - | | Fresh install (no saved profile) | Section-scoped apply from the file (only sections present are written) | | Profile path or file content hash changed | Section-scoped apply from the file (sections absent from the file are preserved in the database) | | Profile unchanged | Fill only paths missing in `APP_CONFIG` (existing values preserved) | Section-scoped replace is **atomic**: Genesis clears and rewrites each touched section inside one database transaction. If any field fails to apply, the transaction rolls back and prior values in those sections remain unchanged — callers never observe a half-cleared section. When startup loading fails (for example a secret reference cannot be resolved during apply), Genesis logs `Config profile apply FAILED` with the profile name, path, error list, and the config paths that were **not** applied. The listed paths identify the values still supplied by their previous or default sources. Genesis **does not** update saved profile metadata (`_profile.path` / file hash), so the next restart retries the apply instead of treating the failed pass as complete. Schema auto-population inserts NULL placeholder rows only for paths with no database row yet; it does not overwrite values written by startup migrations, the UI, or API saves. Normal pod restarts with an unchanged mounted file preserve later UI or API edits. Updating the mounted file — for example through a Helm upgrade or ConfigMap change — triggers a section-scoped reload on the next startup for the sections that file contains; branding, auth, and other sections omitted from the file keep their current database values. See [Setup AI Model — Infrastructure-managed deployments](/docs/Setup/Setup-AI-Model#infrastructure-managed-deployments) for `genesis-config.yaml` mounting details. ## Automation surface | Endpoint family | Use | | - | - | | `/api/config/setup/...` | Validate, full apply, partial apply, export, and inspect setup templates. | | `/api/config/profiles/...` | Save, list, apply, upload, and delete profiles. | | `/api/config/setup/required-secrets` | Review missing secrets before activation. | | `/api/config/setup/sources` | Inspect effective value and priority-chain source for one path or all schema fields. Prefer `path` or `section` query parameters when calling programmatically. | ## Related pages * [Model Universe](/docs/Setup/Model-Universe) * [Branding](/docs/Setup/Branding)