Skip to content
Kesita Kesita Kesita docs

Configuration

Each service owns its environment contract. The checked-in .env.example or .env.template and the service’s typed loader are authoritative; this page intentionally does not duplicate the complete variable inventory.

Rules

Section titled “Rules”
  • Use one canonical name for each value.
  • Keep secrets server-side and out of git, logs, traces, and browser bundles.
  • Use APP_ENV for local, test, staging, or production behavior.
  • Read environment variables through the owning typed configuration module.
  • Give each process only the database, blob, provider, and signing access it needs.
flowchart LR
    Template[Checked-in env template] --> Local[Ignored local overrides]
    Vault[Azure Key Vault<br/>versioned secrets] --> Runtime[Runtime environment]
    Local --> Runtime
    Runtime --> Loader[Typed service loader]
    Loader --> Validate[Startup validation]
    Validate --> Process[App, API or worker]

Run the repository check after changing a contract:

Terminal window
pnpm env:check

Build time and runtime

Section titled “Build time and runtime”
flowchart TB
    Public[NEXT_PUBLIC_* and public origins] --> Build[Image build]
    Build --> Browser[Browser bundle]
    Secrets[DB URLs, signing keys,<br/>provider credentials] --> Runtime[Container runtime]
    Vault[Key Vault] --> Runtime
    Runtime --> Server[Server process]

NEXT_PUBLIC_* values are embedded during the build and require a new image to change. Secrets and server-only configuration are injected at runtime. Docker builds may use obvious non-secret placeholders only when the framework requires them.

Data boundaries

Section titled “Data boundaries”
  • The product app and workers use distinct product database roles. Normal product requests never connect to the legal database.
  • Legal Core and the corpus worker own legal database and corpus-storage access.
  • Product files and corpus originals use separate private blob containers.
  • The document parser receives a short-lived workload token, not application database or blob credentials.
  • DBOS workers receive invocation identity; DBOS administration credentials stay outside worker containers.

Local development defaults to PostgreSQL, Azurite, and simulated providers. --connected reads the ignored infra/env/connected.env for explicit development integrations. Azure environments inject version-pinned secrets from Key Vault and workload access through managed identities.

See deployment for the cloud boundary and the database section for data ownership.