How dev_local, on_prem_enterprise, cloud_shared_saas, and cloud_private presets shape a CortexDB deployment's posture.

Deployment Presets

CortexDB selects a deployment posture via the CORTEX_DEPLOYMENT_PRESET environment variable.

Presets

PresetIntended for
dev_localLocal development and evaluation. The default.
on_prem_enterpriseSelf-hosted, single-organization deployments
cloud_shared_saasMulti-tenant shared cloud deployments
cloud_privateDedicated single-tenant cloud deployments

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

What the preset changes

The preset primarily shapes authentication posture:

  • Under dev_local with no CORTEX_API_KEY set, developer conveniences are enabled: anonymous signup (POST /v1/auth/signup) and the ephemeral dev token minter. The server runs in local no-auth mode and, outside Docker, binds loopback only.
  • Setting CORTEX_API_KEY disables signup and the dev minter (signup returns 503) unless CORTEX_V1_MINTER_ENABLE=1 is set explicitly. The key's value itself becomes a working bearer credential.
  • 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.

Activation model for enterprise controls

Individual enterprise controls (encryption, SIEM, DSAR, residency, and so on) are enabled by their own configuration sections such as security.* and compliance.* — a control is active only when its own config enables it.

Related docs