Configuration

Fine-tune integrations, self-healing, AI Ops, notifications, and system behavior.

Environment Variables

Variable	Default	Description
`PORT`	8080	HTTP listen port
`HOST`	0.0.0.0	Bind address
`NOBA_CONFIG`	~/.config/noba/config.yaml	YAML config path
`NOBA_TRUST_PROXY`	false	Trust X-Forwarded-Host for password reset URLs
`DATABASE_URL`	SQLite	PostgreSQL or MySQL connection string
`NOBA_REDIS_URL`	—	Shared cache URL (e.g. `redis://redis:6379/0`). Required on the enterprise tier (plan=enterprise, state licensed or expired) for cross-worker Microsoft Graph throttle coordination. Community / unlicensed tier is unaffected and falls back to an in-memory cache.
`NOBA_PG_POOL_MIN`	1	Min connections (PostgreSQL/MySQL)
`NOBA_PG_POOL_MAX`	10	Max connections (PostgreSQL/MySQL)
`NOBA_HISTORY_DAYS`	30	Metrics history retention
`NOBA_AUDIT_DAYS`	90	Audit log retention
`NOBA_WORKER_THREADS`	24	Background worker threads
`NOBA_PW_MIN_LEN`	8	Minimum password length
`NOBA_MAX_JOBS`	3	Concurrent automation jobs
`NOBA_JOB_TIMEOUT`	300	Job timeout (seconds)
`NOBA_JOB_RETENTION_DAYS`	30	Job output retention
`NOBA_SOFT_DELETE_DAYS`	30	SCIM soft-delete grace period
`SSL_CERT` / `SSL_KEY`	—	TLS certificate and key paths

Database Backends

NOBA defaults to SQLite (WAL mode, incremental vacuum) for zero-config deployments. For production at scale, migrate to:

PostgreSQL — connection pooling with separate read/write paths. Set DATABASE_URL=postgresql://... and run scripts/init-postgres-schema.py then scripts/migrate-to-postgres.py.
MySQL / MariaDB — full runtime backend with DBUtils connection pooling. Set DATABASE_URL=mysql://... and run scripts/init-mysql-schema.py then scripts/migrate-to-mysql.py.

Pool size is tunable via NOBA_PG_POOL_MIN and NOBA_PG_POOL_MAX. The Settings → Database tab shows the active backend, connection status, and pool configuration.

Cache (Redis / Valkey)

NOBA uses a shared cache for Microsoft Graph throttle coordination across workers (tenant-pause windows, token-bucket accounting against the three published Graph rate limits, pre-429 self-pace signals) and for Graph OAuth2 token caching. The cache backend is selected at startup based on NOBA_REDIS_URL:

Unset — in-memory fallback. Fine for single-worker community deployments. Not safe for multi-worker enterprise deployments: each worker throttles independently against its own in-process bucket, so the real 429 rate against Microsoft Graph scales linearly with worker count.
Set and reachable — shared cache. All workers honor the same tenant pauses and draw from the same token buckets, so throttle behavior matches what the graph layer was designed for.

Starting with beta.27, the enterprise tier enforces this at startup: if the active license plan is enterprise with state licensed or expired, NOBA refuses to start when NOBA_REDIS_URL is unset or when the endpoint does not respond. Trial and grace-period installs log a warning but continue, so first-boot onboarding and trial evaluations still work without Redis pre-configured. Community and unlicensed tiers are unaffected.

Install paths and what you actually get:

Docker Compose (docker-compose.yml) — ships redis:8-alpine (upstream Redis, currently 8.6.2) as a sibling service with AOF persistence, a healthcheck, and a named volume. NOBA_REDIS_URL is pre-wired. No operator action required.
Fedora / RHEL 43+ — sudo dnf install redis installs Valkey (the Linux Foundation fork — AWS/Google/Oracle/Snap/Ericsson maintained) via the valkey-compat-redis meta-package, not upstream Redis. Protocol-compatible with NOBA's redis-py client; set NOBA_REDIS_URL=redis://127.0.0.1:6379/0 in the systemd service environment.
Managed (AWS ElastiCache, Azure Cache for Redis, etc.) — point NOBA_REDIS_URL at the managed endpoint, use rediss:// for TLS and include credentials where required.

Minimum safe server versions as of 2026-04-15 (all close CVE-2025-49844 Lua UAF CVSS 9.9 plus follow-on CVEs):

Upstream Redis: 6.2.20+ / 7.2.11+ / 7.4.6+ / 8.0.4+ / 8.2.3+ / 8.6.0+ (redis:8-alpine ships 8.6.2).
Valkey: 7.2.x / 8.0.7 / 8.1.6 / 9.0.2 — Fedora 43's current valkey-rdma-8.1.6 is clean.

Client library: redis>=7.4 (Python), declared across every NOBA install surface. Zero CVEs against that floor.

Social / SSO (OIDC)

NOBA supports social login via Google, GitHub, Facebook, and Microsoft / Entra, plus a generic OIDC endpoint for Authentik, Keycloak, Authelia, etc. Configuration lives at Settings > Integrations > Authentication and persists inside the socialProviders block of config.yaml.

Starting with beta.29, the Microsoft / Entra flow validates id_tokens end-to-end per OIDC Core 1.0: PKCE (S256), nonce, RS256 signature against the tenant JWKS, iss, aud, exp/iat/nbf with clock-skew leeway, optional at_hash, and tenant allowlist. Every social provider gains PKCE + nonce even on non-OIDC paths, and first-login account creation is gated behind an explicit operator opt-in.

Field	Default	Description
`socialProviders.microsoft.clientId`	—	Azure App Registration Application (client) ID
`socialProviders.microsoft.clientSecret`	—	Azure App Registration secret value (not the secret ID)
`socialProviders.microsoft.tenantId`	—	Required. Directory (tenant) ID. `common`, `organizations`, and `consumers` are rejected unless `allowMultiTenant` is set — this is the NIS2 hardening added in beta.29
`socialProviders.microsoft.allowedTids`	`[tenantId]`	Optional allowlist of Entra tenant GUIDs to accept. Empty list restricts to the single configured `tenantId`. Enforced against the id_token's `tid` claim
`socialProviders.microsoft.allowMultiTenant`	`false`	Explicit opt-in for `/common/`, `organizations`, or `consumers` tenant endpoints. Combined with `allowedTids` — a non-empty allowlist is still enforced
`socialProviders.<provider>.allowJitProvision`	`false`	Allow creating a new NOBA user on first social login. When `false`, social login is rejected unless the email already exists in NOBA. Gate applies per-provider across google / facebook / github / microsoft
`oidcProviderUrl` + `oidcClientId` + `oidcClientSecret`	—	Generic OIDC endpoint (Authentik, Keycloak, Authelia). Discovery (`.well-known/openid-configuration`) is used when available. After discovery, the `issuer` field in the document must match `oidcProviderUrl` per RFC 8414 §3.3 — mismatches are rejected
`oidcVerifySsl`	`true`	TLS certificate verification for the OIDC provider. Starting with beta.30, setting this to `false` is rejected for non-localhost URLs unless `oidcAllowInsecureDev` is also true. Gated to loopback and `.local` / `.lan` / `.test` / `.localhost` / `.internal` hostnames
`oidcAllowInsecureDev`	`false`	Development-only escape hatch that pairs with `oidcVerifySsl=false`. Never set this in production — it disables the TLS requirement on the authorize and token endpoints (ASVS 5.0 V6.4.2)

The Azure App Registration redirect URI must match exactly: https://<your-noba-host>/api/auth/social/microsoft/callback. Test users must belong to the configured tenantId — tokens from other tenants are rejected at the tid-allowlist check even if the Azure app is set to multi-tenant. Starting with beta.30, Entra Conditional Access insufficient_claims challenges surfaced during login are handled automatically: the browser is redirected back to /authorize with the required claims parameter so the user can satisfy the CA policy (MFA, device compliance) and resume the flow — no operator configuration required.

Logout endpoints (beta.31):

RP-initiated logout — clients call GET /api/auth/social/microsoft/logout?token=<noba-token> when the user clicks Sign out. NOBA revokes the session and redirects the browser to Entra's end_session_endpoint with post_logout_redirect_uri back to the login page. No Azure-side configuration required.
Back-channel logout — Azure calls POST /api/auth/social/microsoft/backchannel-logout when the user signs out of another Entra-federated app. To enable, register https://<your-noba-host>/api/auth/social/microsoft/backchannel-logout under App Registrations → Authentication → Front-channel logout URL and Back-channel logout URL in the Azure portal. NOBA verifies the logout_token JWT end-to-end per OpenID Connect Back-Channel Logout 1.0 (signature, issuer, audience, issued-at, required events claim, jti freshness, absent nonce) and terminates NOBA sessions matching the email claim.

Integrations

The 50+ integration catalog is managed through Settings > Integrations where connector setup is implemented. Connector cards expose configuration and connectivity-test flows when supported by that connector.

AI Ops Assistant

Configure under Settings > Integrations > AI / LLM. Supports four providers:

Provider	Default Model	Notes
Anthropic	Claude Sonnet	API key required
OpenAI	GPT-4o	API key required
Ollama	Llama 3	Local, no API key. 120s timeout.
Custom	Configurable	Any OpenAI-compatible endpoint

The assistant receives live infrastructure context with every request. Completely optional — off by default.

Self-Healing

Managed under Settings > Healing. The 6-layer pipeline covers correlation, dependency analysis, planning, execution, verification, and learning for the wired remediation set. A larger action registry, escalation-chain catalog, maintenance-window behavior, and chaos scenario templates are beta surfaces that should be validated per environment before unattended use.

Notifications

Eight channels: Pushover, Gotify, Slack, Discord, Telegram, Email (SMTP), generic Webhook, and ntfy. Composite alert rules support AND/OR conditions with escalation policies.

Themes

Eight built-in themes: Command (default), Dracula, Nord, Tokyo Night, Catppuccin, Gruvbox, Blood Moon, and Enterprise.