Skip to main content

Documentation Index

Fetch the complete documentation index at: https://docs.idun-group.com/llms.txt

Use this file to discover all available pages before exploring further.

The standalone has two distinct authentication surfaces. This page covers the admin panel; for agent-route SSO, see SSO.
SurfaceRoutesMechanismWhere it lives
Admin panel/admin/*, /login/, /admin/api/v1/*none or password (bcrypt + signed session cookie)Environment variables
Agent runtime/agent/* (chat side)OIDC JWT validation with per-user allowlistssso: block in config — see SSO
Health and metadata routes (/health, /_engine/info) stay open on both surfaces. Treat the engine as a process running inside a trusted boundary; see Production hardening for network-layer controls.

​
Environment variables

The admin panel is configured by environment, not config. The mode is selected by IDUN_ADMIN_AUTH_MODE.
VariableDefaultDescription
IDUN_ADMIN_AUTH_MODEnoneAdmin gate. none for laptop dev; password for containers and shared deployments.
IDUN_ADMIN_PASSWORD_HASHemptyBcrypt hash that seeds the singleton admin row on first boot. Required when auth_mode = password. Generate with idun hash-password.
IDUN_SESSION_SECRETemptyAt least 32 characters. Signs the idun_session cookie. Required when auth_mode = password; startup fails fast if shorter.
IDUN_SESSION_TTL_HOURS24Session cookie lifetime in hours (range 1..720). Sliding renewal extends the cookie on every request.
IDUN_ALLOW_OPEN_ADMINfalseOpt-in flag that lets auth_mode=none bind 0.0.0.0 / ::. Containers and trusted networks only. Without this, an open-admin process is forced to loopback.

​
IDUN_ADMIN_AUTH_MODE=none

Every admin route is open. No login screen. Anyone who can reach the process can read and write configuration through /admin/. Intended for laptop development. The runtime binds to 127.0.0.1 by default so the open admin is not exposed beyond localhost. To bind to 0.0.0.0 (e.g., inside a container) you must set IDUN_ALLOW_OPEN_ADMIN=1 — the runtime refuses otherwise.

​
IDUN_ADMIN_AUTH_MODE=password

A single admin user logs in at /login/ with a password. The standalone signs an idun_session cookie (HttpOnly, SameSite=Lax, Secure when behind HTTPS) and gates /admin/* on it. The published container image flips this mode on by default. Setup is two env vars at first boot: 
# 1. Generate the bcrypt hash on a workstation (never on the server).
idun hash-password
# Password: ********
# Confirm:  ********
# $2b$12$abc...   <- copy this

# 2. Inject both at deploy time.
IDUN_ADMIN_AUTH_MODE=password \
IDUN_ADMIN_PASSWORD_HASH='$2b$12$abc...' \
IDUN_SESSION_SECRET="$(openssl rand -hex 32)" \
idun serve
IDUN_ADMIN_PASSWORD_HASH is consumed only on first boot to seed the singleton admin row. Subsequent boots ignore the env var. Rotate the password from the admin UI, or truncate the standalone_admin_user table and reboot to re-seed from the env.
The standalone supports exactly one admin user. The standalone_admin_user table has a fixed primary key of "singleton" and the admin URL never carries an id. There is no allowlist or multi-user concept for the admin panel today. For per-user policy, restrict access at the network layer (VPN, mTLS gateway, IP allowlist on the load balancer). See Production hardening for the full checklist.

​
What’s next

SSO

Per-agent OIDC for /agent/* runtime routes, with allowed_domains / allowed_emails allowlists.

Production hardening

Env-var checklist for password mode + reverse-proxy / TLS notes.

Troubleshooting

What agent_not_ready and reload-pipeline errors mean.
Last modified on May 20, 2026