Deployment Presets
How dev_local, on_prem_enterprise, cloud_shared_saas, and cloud_private presets shape a CortexDB deployment's posture.
CortexDB selects a deployment posture via the CORTEX_DEPLOYMENT_PRESET environment variable.
Presets
| Preset | Intended for |
|---|---|
dev_local | Local development and evaluation. The default. |
on_prem_enterprise | Self-hosted, single-organization deployments. |
cloud_shared_saas | Multi-tenant shared cloud deployments. |
cloud_private | Dedicated single-tenant cloud deployments. |
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_KEYon a network-exposed bind auto-generates a key and requires it; run unauthenticated for local dev only withCORTEX_INSECURE_NO_AUTH=1(serves every request asuser:local, binds loopback). SetCORTEX_API_KEY=<secret>to require bearer auth — the key's value itself becomes the credential. - The in-binary dev minter (
POST /v1/auth/signup,POST /v1/auth/tokens) is off by default — both return503 NOT_CONFIGUREDunlessCORTEX_V1_MINTER_ENABLE=1is set explicitly. - Production presets expect token issuance from an external OIDC provider or the separate
cortex-auth-refissuer — 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 — 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.
Running a multi-tenant SaaS?
The cloud_shared_saas preset is the multi-tenant posture — one deployment, many isolated tenants. See
Multi-Tenancy for how tenants map to token audiences, the isolation
guarantees, and how to provision them.