Deployment Presets

CortexDB selects a deployment posture via the CORTEX_DEPLOYMENT_PRESET environment variable.

Presets

These four values are the complete set. (Older documentation referenced startup / growth / enterprise names — those are not valid preset values.)

What the preset changes

The preset primarily shapes authentication posture:

• Auth is on by default. A server with no CORTEX_API_KEY on a network-exposed bind auto-generates a key and requires it; run unauthenticated for local dev only with CORTEX_INSECURE_NO_AUTH=1 (serves requests without a token as user:local or the named X-Cortex-Actor; it does not restrict the bind, so publish the port on loopback only). Set CORTEX_API_KEY=<secret> to require bearer auth — the key's value itself becomes the credential. An X-Cortex-Actor header with no bearer is rejected on every preset (see Authorization).
• The in-binary dev minter (POST /v1/auth/signup, POST /v1/auth/tokens) is off by default — both return 503 NOT_CONFIGURED unless CORTEX_V1_MINTER_ENABLE=1 is set explicitly.
• Production presets expect token issuance from an external OIDC provider or the separate cortex-auth-ref issuer — the in-binary minter is dev-only and ephemeral.
• Which scope types a new scope may use. cloud_shared_saas (also the hosted cloud) allows 10; on_prem_enterprise and cloud_private add global and system; dev_local also adds debug and temp. See Allowed scope types.
• Not the forget default, which is the same on every preset: a /v1/forget that names no cascade runs derived_only, which keeps the memories themselves.

Activation model for enterprise controls

Individual enterprise controls (encryption, SIEM, DSAR, residency, and so on) are enabled by their own configuration sections — security.* and compliance.*. A control is active only when its own config enables it; the preset does not turn them on. See Security & Compliance for the per-field walkthrough.

Related docs

• Multi-Tenancy · Enterprise Security
• Backups & Disaster Recovery
• Admin endpoints