Skip to main content
Celum is configured entirely through the environment. This page lists what the backend and the dashboard actually read — nothing here is aspirational, and anything absent from this page is ignored if you set it.
Values in angle brackets are placeholders. Defaults shown as — mean the variable is empty unless you set it, and the feature it belongs to stays off.

Core

Without KUBECONFIG_PATH, requests that name no supervisor use Celum’s own in-cluster service account when Celum runs inside Kubernetes, and ~/.kube/config otherwise.

Authentication

Leaving SESSION_SECRET unset does not fail the boot — the backend generates a random key and logs a warning. Every session is then invalidated on restart. Set it explicitly in any deployment you expect to restart.

Authorization

Observability

Integrations

Celum does not write to Git. GITLAB_URL, GITLAB_TOKEN, GITLAB_PROJECT_ID and GITLAB_BRANCH, which older deployments set, are not read; setting them does nothing.

Appliance

The Celum appliance writes these into the backend’s environment. Do not set them on another deployment.

Secret store

Credential-shaped values can come from Vault or Azure Key Vault instead of the environment. Set SECRET_BACKEND to switch it on.

Which values the store resolves

Under Vault the mount is prepended, so backend/github is read from celum/backend/github by default. Non-credential values, such as URLs and IDs, stay in the environment.
VAULT_BOOTSTRAP_ROLE_ID / VAULT_BOOTSTRAP_SECRET_ID are a third credential and the only one that can change Vault itself: with them the backend may enable auth mounts and write celum-eso-* policies, so that a new supervisor’s External Secrets Operator can be wired without a human in Vault. That is a much larger grant than reading and writing secrets, which is why it is opt-in, off by default, and gated by VAULT_BOOTSTRAP_ALLOW — an empty allowlist denies everything, and the backend logs the effective list on every boot that has bootstrapping enabled.

Precedence

1

The store wins

A non-empty value from the store is used, and the environment variable is ignored.
2

Absent or empty falls back to the environment

A missing secret, or one present but empty, falls through to the environment variable. A mistyped path therefore degrades to the old value rather than blanking the credential.
3

Any other error fails the boot

Denied, sealed, or unreachable stops the backend from starting. It does not fall back — booting with empty credentials would log everyone out and break integrations silently.Three credentials are optional and do not stop the boot: ALERT_WEBHOOK_TOKEN, SENTRY_DSN and APPLIANCE_IMAGE_S3_SECRET_KEY. When the store denies or cannot serve one of them, the backend uses the environment value. If that is empty too, the feature stays off. The startup line then names the source as env(after <backend> error) or unavailable(optional).
One log line at startup names every credential and where it came from — env, env(fallback), the backend name, or ERROR. Names and sources only, never values. Check it when a hotfix value you set in the environment appears to have no effect: store-wins means it was ignored.
With a store configured, an empty session secret is a boot failure, not a warning. Auto-generating one would invalidate every session on each restart, so the backend refuses to start until backend/session#secret exists.

Dashboard

The Next.js dashboard reads a much smaller set:
BACKEND_PUBLIC_URL is injected at request time rather than baked in at build time, so one image runs against any environment. No NEXT_PUBLIC_ variables are used.

Quickstart

A working Compose stack using these variables.

Authentication & IAM

What the OIDC variables do in the sign-in flow.

Permissions model

IAM_ENABLED and IAM_DEBUG in context.

Glossary

Terms used across these settings.