Skip to content

[config] Phase 6: DB-backed runtime config + per-project overrides #200

Description

@mfittko

Summary

Introduce a DB-backed runtime configuration layer (hot-reloadable) with safe, validated per-project overrides, reducing env var sprawl and enabling operational tuning without redeploys.

Source doc: docs/issues/planned/phase-6-runtime-config-db-overrides.md

Scope (high-level)

  • Split config into:
    • Bootstrap config (env/file; secrets + connectivity; restart required)
    • Runtime config (DB-backed; hot-reloadable; audited)
  • Add a typed config registry (key, type, scope, defaults, validation rules)
  • Add global values + per-project override values with clear precedence
  • Move API provider allowlists from YAML into DB-backed Provider Profiles (with YAML fallback for a transition period)

Tasks

  • Define runtime config registry (types, scopes, validation, sensitivity)
  • DB schema: runtime config tables for global + per-project overrides
  • Add in-process cached snapshot + safe reload mechanism
  • Management API: CRUD for runtime config keys/values; audit all changes
  • Admin UI: view/edit runtime config (minimal, safe)
  • Provider Profiles: model + management API + loader
  • Back-compat: config/api_providers.yaml fallback (read-only) during transition
  • Tests: validation, precedence rules, reload behavior, performance (no request-path regressions)

Acceptance Criteria

  • Runtime tunables can be changed via management API without restart
  • Per-project overrides work and are restrictive where appropriate
  • All changes validated + auditable
  • Request path reads are constant-time from a cached snapshot
  • No secrets moved into DB runtime config

Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Fields

    No fields configured for issues without a type.

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions