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 byIDUN_ADMIN_AUTH_MODE.
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:
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.